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Introduction 


Project success is one of the enigmas within the project 
management discipline. No one is sure how to define project 
success, what contributes to projects succeeding or failing or 
how to measure the success of projects. This is even worse when 
it comes to Information System (IS) projects. The deliverables 
of IS projects are seldom seen apart from some application that 
users and customers use as part of their daily routine. The only 
time that the deliverable of an IS project is visible and tangible 
is when the focus of the IS project is to replace or upgrade 
hardware. 


E investment in information 
technology 


Vast amounts of money are spent annually on Information 
Technology (IT). The rationale is that organisations cannot 
function without IT and therefore it warrants the large amounts 
of money that are invested in IT. A report by Lovelock et al. 
(2017) indicated that IT spending is rising on an annual basis and 
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TABLE 1.1: Information technology spending world. 


Spending (Billions of Years 

dollars) 2014 2015 2016 2017 2018 2019 2020 
Data centre systems 166 171 170 175 176 178 181 
Enterprise software 310 314 333 355 380 407 436 
Devices 649 646 588 589 589 593 593 
IT services 897 866 900 938 981 1029 1081 
Communications services 1541 1399 1384 1408 1426 1441 1462 


Total 3564 3395 3375 3464 3553 3648 3752 


Source: Lovelock et al. 2017. 


will continue to rise for the foreseeable future. Annual growth 
is predicted to be around 2.7%. The prediction is illustrated in 
Table 1.1. 


It is evident from the amounts in Table 1.1 that companies as 
well as governments spend a lot of money on IT-related services. 
The annual increase of 2.7% also indicates that IT is a continuous 
investment. This continuous investment in IT is also evident 
from a South African perspective where it is expected that 
South Africa will spend $10.5 billion in 2017. This is 0.3% of the 
worldwide spend on IT. Research indicated that South African 
companies spend billions of rands on IT services as illustrated in 
Figure 1.1. 


The South African spend on IT services is 0.5% of the 
worldwide spend on IT services. That is an amount of $5bn. IT 
services normally include, (1) IS consulting, (2) system integration, 
(3) maintenance, support and upgrades, (4) full outsourcing 
and (5) hosting. The remainder is spent on devices, enterprise 
software and communication services. Given this amount of 
money that is spent on IT, the question is raised whether this 
adds any value to organisations, irrespective of whether they are 
public or government entities. The amount that is annually spent 
on IT is a mere 0.7% of South Africa’s gross domestic product. 


One of the control objectives within COBIT 5 (EDMO2) states 
that organisational leaders should receive the optimal value from 
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FIGURE 1.1: Information technology services spending - South Africa. 


their investments in IT services and IT assets (IT Governance 
Institute 2012). Even from a governance perspective, IT 
investment should make logical sense and contribute to the 
overall benefit of the organisation. IT investments are generally 
implemented through programmes or projects that create 
benefits and ultimately business value (Curley, Kenneally & 
Carcary 2016). 


E Value of IT 


IT provides value to entire organisations because they reach 
out to the world through IT. IT is not perceived as a stand-alone 
entity or division because it is integrated within the organisation, 
and organisations cannot perform without IT. When IT does not 
deliver value, then the chances are that the organisation will also 
not reach its optimum performance. 


The questions that organisations need to answer are: Firstly, 
What value is IT to the organisation? and secondly, How can this 
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value be measured? The value of IT can be determined through 
the following equation: 


Value of IT = Benefits - Costs 


Given this equation, organisations should determine the 
benefits that they receive from IT and also how much it costs to 
implement, maintain and upgrade IT. 


Determining the costs of IT is relatively easy, but organisational 
leaders should not just take the direct costs into account but 
also the hidden or overlooked costs. Hidden costs include, but 
are not limited to, recruiting, training, office space, software 
enhancements (upgrades), software maintenance (bug fixes), 
hardware upgrades, hardware maintenance and scheduled 
outages. Ascertaining the benefits of IT is not easy. The easiest 
way might be to shut down the entire IT department for a day or 
two and determine the impact on the organisation based on lost 
sales and opportunities or the negative impact on the brand of 
the organisation. 


Irrespective of what metrics are used to determine the 
benefits of IT, a general way to determine the benefits is to use 
financial calculations such as Return on Investment, Payback 
Period or Net Present Value. The results from these financial 
calculations normally indicate whether an investment in IT is 
a safe and profitable investment. The benefits of IT are also 
intangible and these are the challenge that organisational 
leaders face. How do organisations quantify the intangible 
benefits of IT? 


Harris, Herron and Iwanicki (2008) provided a framework 
that can be used to determine the value of IT. The value of IT is 
determined over a period of time and is based on the investment 
in IT and also the benefits of IT to business. A simplified version 
of the framework is illustrated in Figure 1.2. 


The value of IT to business is determined by the degree 
whereby processes are influenced and changed, how sales have 
improved and whether there is a growth in revenue at the end 


Chapter 


Business financial value 


Business investments Business operational value 


Ayyiqisuodse. 
juawbeue; 
ssoulsng 


Business process value 


IT Application business value 


T 
Managment 
responsibility 


IT investments 
IT Infrastructure business value 


Time for business impact 


FIGURE 1.2: Information technology value framework. 


of the day. Figure 1.2 actually highlights that everyone in the 
organisations are responsible for determining the value of IT. 
The IT department provides IT as an enabler for business and 
it is up to business to determine to what extent they want to 
embrace IT. 


IT investments are normally realised through projects and the 
more successful the projects, the more value is created from the 
IT investments. The following sections briefly discuss the success 
rates of IS projects and highlight that organisations do not obtain 
value from IT projects and therefore also not from IS. 


Information technology is the cumulative word that is used 
to describe everything and anything that has vaguely to do with 
computers. IT consists of three components, of which the first 
is computer science. This discipline focuses on topics such as 
discrete structures, human-computer interaction, programming 
fundamentals, graphics and visual computing, algorithms and 
complexity and programming languages amongst others. 
The second layer or component is information technology. 
This discipline focuses on the selection, creation, application, 
integration and administration of computing technologies. 
Computing technologies include networking, databases, web 
systems and information security. Information systems is 
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the third layer and focuses in general on the improvement of 
organisational processes and the design and management 
of enterprise architecture. Topics within the IS field focus on 
data and information management, enterprise architecture, IT 
infrastructure, IS project management, systems analysis and 
design as well as IS strategy. 


This study focuses specifically on the third layer, that is, the IS 
layer and more specifically on IS project management. 


HIS project success rates 


IS projects are the vehicles that organisational leaders use to 
implement the IT strategy. The logical conclusion is that when IS 
projects fail or are perceived as not delivering on all the benefits, 
then the IT strategy is not fully implemented. This then creates 
an imbalance where the IT strategy does not fully contribute to 
the organisational strategies. 


Information system project success has been studied over 
the last couple of decades by academics and practitioners 
alike. The reason for this almost frenetic research is that there is 
enough evidence to indicate that IS projects are still failing at an 
alarming rate. This was the case two decades ago, and it is still 
the case in the late 2010s. Research is performed internationally 
by the Standish group which produces the Chaos Chronicles, 
and in South Africa the research on IS project success rates is 
called the Prosperus reports (Labuschagne & Marnewick 2009; 
Marnewick 2013; Sonnekus & Labuschagne 2003). Results from 
the international research are shown in Figure 1.3. 


The results indicate clearly that something drastically is wrong 
as the rate to successfully implement an IS project is on average 
28%. This implies that 70% of IS projects either do not add value 
or add limited value to organisations. Of even greater concern is 
the fact that the success rates have stagnated at around 30% for 
the last decade, implying three things: 
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FIGURE 1.3: International information system project success rates. 


1. IT departments and professionals actually do not care about 
these results. 

2. We do not understand the complexity of IS projects. 

3. We are measuring the success of IT projects incorrectly. 


IS projects success rates within South Africa do not look much 
better as indicated in Figure 1.4. 


Although the South African success rates look better than the 
international success rates, South African companies are in the 
same boat as international companies where a mere third of IS 
projects are perceived as successful. 


When these results are translated into monetary value, a 
gloomy picture is created as indicated in Table 1.2. The results 
indicate that $17 820bn are wasted on IS projects that either do 
not deliver or deliver little value to a company. 


The South African perspective is just as bleak as indicated in 
Table 1.3. On average, 57 cents are wasted for every one rand 
spent on IT. 
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FIGURE 1.4: South African information system project success rates. 


TABLE 1.2: Information technology waste - worldwide. 


Year Billions of dollars 

Spending Waste 
2014 3564 2566 
2015 3395 2444 
2016 3375 2430 
2017 3464 2494 
2018 3553 2558 
2019 3648 2627 
2020 3752 2701 
Total 24 751 17 820 


The results depicted in this section clearly indicate that 
companies need to address the success rates of IS projects as 
a matter of urgency. Information technology cannot continue 
to be seen as a black hole into which money disappears and 
little or no value is created for the company and all the relevant 
stakeholders. 
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TABLE 1.3: Information technology waste - South Africa. 


Year Billions of rands 

Spending Waste 
2015 56.9 324 
2016 63 35.9 
2017 65 a7 
2018 70 39.9 
2019 75 42.8 
2020 87.3 49.8 
Total 417.2 237.8 


E Strategic alignment of IT 


Projects are generally perceived as the vehicles to implement 
strategies (Cooke-Davies 2016; Martinsuo, Gemünden & Huemann 
2012; Marnewick & Labuschagne 2010). These strategies can 
be organisational strategies or they can be strategies specific 
to a division within the organisation. IT strategies are also 
implemented through projects. 


IT strategies are derived from the organisational strategies 
and are therefore aligned with the organisational strategies 
(Marnewick & Labuschagne 2011). This implies that when the 
organisational strategies change, the IT strategies should also 
change and be realigned with the organisational strategies. 
Within the COBIT governance framework, EDMO1 (Ensure 
Governance Framework Setting and Maintenance) focuses on 
the alignment of the IT strategy with the organisational strategy 
(IT Governance Institute 2012). EDMO1 measures three specific 
concepts related to the IT strategic alignment: 


e The percentage of organisational strategies supported by IT 
strategies. 

e The level of stakeholder satisfaction with the intended IT 
portfolio. The IT portfolio consists of various programmes and 
projects that will implement the IT strategy and ultimately the 
organisational strategy. 
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e The percentage of IT-value drivers that are mapped to the 
organisational value drivers. 


Given the notion that projects are the vehicles to implement 
the IT strategies, organisational leaders should then be seriously 
concerned. The IS project success results clearly highlight the 
notion that IT strategies cannot be fully implemented because 
of the large number of IS projects that are failing. It is evident 
that only a small percentage of the IT strategy is implemented 
which in turn implies that IT strategies are not necessarily 
supporting the organisational strategies. This raises the 
question whether IT adds value to the organisation at large as 
suggested by EDMO2. 


This non-delivery of IT strategies creates a governance 
concern. The question that needs to be answered is what the 
real value is that IT brings to the organisation at large. There 
is no doubt that organisations cannot function without IT, but 
the question is whether IT is of strategic value or operational 
value. The results suggest that IT is more of operational value 
than strategic value. 


E Types of IS projects 


There is no one-size-fits-all solution when it comes to the 
implementation of IS projects. IS projects come in different 
flavours and IS project managers should take cognisance of 
these different types of projects. 


Infrastructure 


The implementation of IT infrastructure is one of the least 
complex projects to realise. These types of projects focus on 
the implementation of hardware such as networking equipment 
or the installation of desktops and printers. What makes these 
types of projects less complex is the simplicity and predictability 
to implement. For example, when an organisation needs to 
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relocate offices, new network points need to be installed. The 
project schedule is easily created, as the project manager will 
know more or less how long it takes to install a network point 
and that the time needed is merely multiplied by the number of 
network points. The same logic applies when printers or desktop 
workstations need to be installed. 


Customisation 


Customisation of software is a little bit more complex than 
the implementation of infrastructure. Software products 
do not necessarily suit the needs of an organisation as is. 
To cater for the specific needs of an organisation, software 
needs to be customised or changed. This change is more a 
cosmetic change to the existing software product than a major 
change to the internal workings of the software package. 
Customisations might include the change of financial reports 
to suit legislation or a change in the look and feel of an order 
capture screen. 


Integration 


Integration on the other hand is more complex than 
customisation. Integration focuses on sending data (information) 
between two. software products. This implies that the 
software developer needs to understand the data structure of 
both products and the way that data is stored. Integration focuses 
on the conversion of data from the one product to the 
other product and vice versa. Planning for integration is also 
tricky as it is not always that easy to estimate the duration of any 
integration. 


System implementation (full) 


A full system implementation is extremely complex and 
contains a lot of uncertainties. A full system implementation 
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is typically when organisations decide to replace one system 
with another system. This might be the case when an Enterprise 
Resource Planning (ERP) system replaces a legacy system. 
This type of implementation requires all hands on deck and 
normally includes infrastructure replacements, customisations 
and integrations with other systems. 


System implementation (upgrade) 


An upgrade is also complex and consists of a level of uncertainty 
but not to the extent of a full system implementation. The 
difference between an upgrade and a full implementation is 
that the basic building blocks are in place. The upgrade focuses 
on staying current with the latest version of the software. 
The upgrade might include the upgrade of infrastructure but 
definitely some customisations and integrations. Customisations 
and integrations can follow different methods of implementation, 
that is the traditional Waterfall method or an Agile approach. 


E Method of implementation 


Various methods exist to implement IS projects, but it is not the 
purpose of this book to discuss all the different methods. The 
two most important methods are the Waterfall model and Agile 
and its various variations. 


Waterfall model 


One of the first structured approaches developed was the 
Waterfall process. In this model as illustrated in Figure 1.5, the 
process is executed in an orderly sequence (Leffingwell 2011). 
Each stage is completed before the next stage starts (Leffingwell 
2011). Requirements are agreed, a design is created after which 
the coding follows and testing is performed. The final step is 
integration. In practice when implementing complex systems, it 
is almost impossible to have requirements that do not change 
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Source: Dorfman and Thayer (2000). 
FIGURE 1.5: Waterfall model. 


during the implementation life cycle (Dorfman & Thayer 2000). 
The advantage of the model is that it is a simple process to 
manage (Sommerville 2001). 


An iterative approach is used in the Waterfall model where 
each successive step provides feedback to a previous step (Royce 
1970). However, the Waterfall model is mostly interpreted as a 
sequential linear process (Boehm 2006). 


Agile approach 


Agile methodologies were initially authored to manage the 
development of software development projects, but have been 
extended because of their popularity and success with handling 
most types of IS projects. Agile software development is amethod 
of software development that is characterised by an emphasis 
on, (1) people, (2) communication, (3) working software and (4) 
responding to change. 


The working definition of Agile methodologies can be 
summarised as a group of software development processes that are 
iterative, incremental, self-organising and emergent. Hence from a 
theoretical perspective Agile methodologies can be defined as: 
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e Iterative: The word iterative is derived from iteration which 
carries with it connotations of repetition. In the case of Agile 
methodologies it is not just repetition but an attempt to solve 
a software problem by finding successive approximations to 
the solution starting from an initial minimal set of requirements. 

e Incremental: Each subsystem is developed in such a way that 
it allows more requirements to be gathered and used to 
develop other subsystems based on previous ones. The 
approach is to partition the specified system into small 
subsystems by functionality and add a new functionality with 
each new release. 

e Self-organising: This term introduces a relatively foreign 
notion to the management of scientific processes. The usual 
approach is to organise teams according to skills and 
corresponding tasks and let them report to management in a 
hierarchical structure. In the Agile development setup the 
‘self-organising’ concept gives the team autonomy to organise 
it to best complete the work items. 

e Emergent: The word implies three things. Firstly, based on the 
incremental nature of the development approach the system 
is allowed to emerge from a series of increments. Secondly, 
based on the self-organising nature a method of working 
emerges as the team works. Thirdly, as the system emerges 
and the method of working emerges a framework of 
development technologies will also emerge. 


It must be noted that for the purpose of this book and study, 
reference is made to Waterfall projects and Agile projects. Waterfall 
projects are IS projects that make use of the Waterfall method to 
deliver the software that forms part of the larger project. Similarly, 
Agile projects are projects that make use of Agile methods to 
develop software. These terms are strictly not the correct terms 
but are used for ease of reading and understanding. 


Previous studies uncovered various factors that contribute to 
IS project success (Marnewick 2013; The Standish Group 2014). 
Although complexity was defined as a factor, complexity as a 
construct was never investigated as a factor itself. The purpose 
of this study is to understand complexity within the IS domain 
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and to determine the relationship between IS project success and 
complexity. This was achieved through a quantitative approach. 


E Research methodology 


A quantitative approach was used for this study as the primary aim 
was to determine current IS project success rates as well as the 
relationship with complexity (Denscombe 2010; Thomas 2003). 
The rationale for this decision was two-fold. This study builds on 
previous studies (Labuschagne & Marnewick 2009; Marnewick 
2013; Sonnekus & Labuschagne 2003), and IS success rate 
trends need to be established. This can only be done through a 
longitudinal study that is embodied within a quantitative approach. 
The second reason was that it ensured that each respondent was 
presented with the exact same questions in the same sequence. 
Moreover, this allowed the researchers to reliably aggregate and 
compare the responses between different sample subgroups. 


Probability sampling was used as this research focused on 
providing a representative view of the unit of analysis for the 
purpose of generalisability (Sekaran 2003). Simple random 
sampling was selected because it not only provides results which 
are highly generalisable, but also adequately represents the 
target population. Furthermore, as this form of sampling exhibits 
low bias, the results obtained would provide an objective view of 
the research problem. 


The instrument used for this study was a questionnaire. The 
questionnaire was divided into four sections. The first section 
focused on the biographical information of the respondent. 
The second part focused on the type of IS project that is under 
investigation. Two important aspects that form part of an IS 
project had to be answered. The first aspect speaks to the type 
of IS project and the second aspect speaks to the type of method 
that was used to implement the IS project. 


The third section of the questionnaire dealt with the notion of 
IS project success. This section was designed around the model 
of Bannerman and Thorogood (2012). Each component within a 
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success level was measured based on a Likert scale. Respondents 
could choose between poor, fair, good, very good and excellent. 
This was applicable to processes, deliverables, business and 
strategic success. Actual figures were provided for cost and time 
that form part of project management success. 


The fourth section of the questionnaire focused on the 
complexity of the project. Five types of complexity had to be 
assessed based on a Likert scale. Respondents could choose 
between simple, relatively simple, fairly complex, complex 
and very complex. Organisational complexity consisted of 34 
types of complexity, technical complexity consisted of 12 types, 
environmental complexity consisted of 13 types, dynamics 
consisted of 6 types and uncertainty consisted of 10 types. The 
types of complexity are discussed in detail in Chapter 3. 


E Book layout 


The book is divided into the following chapters for ease of 
reading and referencing. Chapter 2 focuses on IS project 
success and what constitutes IS project success. The framework 
of Bannerman (2008) is used to describe IS project success. 
Success is not just a yes or no answer but can be measured at 
various levels that might have an impact on one another. This 
model or approach provides organisational leaders with a better 
way to measure and determine IS project success. 


The third chapter unpacks the notion of complexity. This is 
done through the lenses of IS projects. The outcome is that IS 
projects are complex and that five types of complexity influence 
IS projects. Each of these five complexity constructs consists 
of elements that in turn consist of features. This makes the 
management of IS projects extremely complex. 


Chapter 4 analyses the success of IS projects. Each level of 
the framework is used to determine project success. For each 
level, the overall success is determined as well as the success for 
the Waterfall and Agile projects. The results highlight that there 
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is an improvement in overall IS project success and that Agile 
projects might be more successful than Waterfall projects. 


Chapter 5 investigates the results of IS complexity. To simplify 
the matter, the top five and bottom five elements are provided 
for each complexity construct. This is also done for all IS projects 
and specifically for the Agile and Waterfall projects. 


Chapter 6 focuses on the relationship or symbiosis between 
IS project success and complexity. The results indicate that a 
symbiotic relationship exists between IS project success and 
complexity. The various complexity constructs are mapped to 
the levels of IS project success. 


Chapter 7 concludes the book. A synopsis is provided to 
enable organisational leaders and IS project managers to utilise 
the information and make better decisions, increase IS project 
success rates and address complexity within IS projects. 


Demystifying project 


success 


Most IS projects fail (Johnson 2014; Marnewick 2013a, 2013b). 
In fact, almost two thirds of IS projects evaluated since 2003 
could not be classified as success stories. Figure 2.1 indicates the 
lack in progress made by project management professionals in 
increasing the rate of delivering success. 


The South African results approximate the international results, 
indicating that there are not simply local conditions at play. There 
must be something at the heart of IS project management that is 
actively driving these results. 


Billlons of rands are spent each year on IT services, and 
investment is set to grow in this area (Lovelock et al. 2017). No 
wonder organisational leaders are losing confidence in project 
management methodologies when almost two-thirds of IS 
projects fail and investment is lost, or the project does not deliver 
on its promise. 


Much has been written on why projects fail (Budzier & 
Flyvbjerg 2015; Erasmus, Marnewick & Joseph 2014; Joseph 
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Source: Joseph, Erasmus and Marnewick (2014). 
FIGURE 2.1: South African and global information system project success rates. 


et al. 2014; Marnewick, Erasmus & Joseph 2016a, 2016b; Ngoma 
& Erasmus 2016). This knowledge has been with project 
professionals for a very long time. It is known why projects fail. 
It is known what should be done to ensure projects are delivered 
successfully (Cooke-Davies 2002). Yet, project managers cannot 
seem to increase their project delivery success rates. This is the 
annunciation of Cobb’s paradox: If we know why projects fail and 
how to prevent it, why do we still fail at projects? (Bourne 2011). 


The answer could lie in the fact that much research has been 
done in the technical aspects of project management, while 
limited studies are done inthe so-called ‘soft issues’ around project 
management. It may very well be that the identified inhibiters 
and enablers of project success are only partially responsible for 
project outcomes and more remain to be uncovered. What may 
complicate matters even more is the possibility that IS projects 
do not fit the traditional paradigm of project management as we 
know it today. Perhaps IS projects are so different that project 
management should be rethought in its entirety in order to deal 
with the idiosyncrasies of IS project management. 


Demystifying project success 


What is abundantly clear is that should IS project delivery 
continue on the current trajectory, we may very well not 
encounter the term ‘IS Project Management’ in future. Investment 
decision-makers will look elsewhere to achieve the goals that 
formal project management methodologies promised. 


E The evolution of success 


One of the formal definitions of a project is that it is a set of 
predetermined activities that need to be completed incrementally 
in order to achieve a unique, predefined objective through the 
use of resources in a specified time frame (Project Management 
Institute 2013; Schwalbe 2016). At face value, it is a relatively 
simple task to provide a deliverable in the manner a customer 
requests. 


Tools, techniques and processes that were already available 
to operations were adapted to compensate for the closed-off 
time frame in completing these activities. These were harnessed 
into formal project management methodologies. This was the 
approach of the 1970s, although projects have been attempted 
and completed for centuries and millennia before then. 


Much of past research was focused on the mechanisms, tools 
and techniques for managing a project properly. Bodies such as 
the Project Management Institute and Association for Project 
Management have developed innumerable toolkits, standards, 
methodologies and frameworks to assist project practitioners in 
this endeavour. 


But that was not the end of the story. Organisational leaders 
discovered that even though they had to manage project 
managers through strict quantifiable metrics, such as the 
triple constraint, customers were often satisfied with the end 
product, although they might not have been satisfied in the 
manner of its delivery. The product became then the priority 
at the end of the day. The end seemed to justify the means 
(Davis 2014). 
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Success varied by industry, yet large amounts were and 
are invested in project management training and capabilities. 
As organisations continued to grow, so did the scale and 
complexity of projects. So much so that megaprojects could 
not be managed by a single individual but through committees. 
Megaprojects had strategic significance and as such they were 
broken down into smaller projects. Programmes emerged. 
Some oddball projects were encountered that did not seem 
to fit in with the strategic intent of the organisation. Portfolio 
management was then required to select and reject projects that 
would have the greatest benefit in supporting the organisations’ 
strategic objectives. However, complexity grew even more as 
organisations sought to gain competitive advantage through 
projects. Market forces dictated that organisations needed to take 
decisive action in attempting to gain and maintain market share. 
Project management has now become an important strategy- 
achieving tool through portfolio management. Any selected 
project has to contribute to achieving the greater organisational 
strategic intent. 


Ultimate project success is now characterised by strategically 
effective organisations. But what does that mean to the project 
manager that is currently experiencing his or her first project 
that simply cannot be steered to success, regardless of what 
interventions are put in place? The so-called ‘project of death’. 


E Project outcomes 


No discussion on project management success can be held 
without referring to the seminal work performed by Paul 
Bannerman. He rightly deduced that project success is achieved 
on multiple levels and developed a framework to illustrate this 
concept (Bannerman 2008; Bannerman & Thorogood 2012). 


Figure 2.2 lays out the case that project success is defined 
from various perspectives. In Level 1, project success is defined 
by the successful implementation of project management tools 
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Return on investment 


Tactical (Derived value) Strategic 


Stakeholders 


Technical Project Client/User Business: Internal External 
Level 1 Level 2 Level 3 Level 4 Level 5 
Project Product Organisational benefit 
Process PM Deliverable Business Strategic 
success success success success success 


Source: Adapted from Bannerman (2008). 
FIGURE 2.2: Five levels of project success. 


and techniques. Success at this level is determined through the 
selection of appropriate tools and how effective they were used. 


In Level 2, success is measured according to whether the 
project has met the triple constraint of time, cost and scope. 
A failure to meet any of these technical constraints would result 
in total project failure at Level 1 and Level 2. 


Customers, clients or users are usually less concerned 
about whether the projects have used the appropriate technical 
tools. They may be somewhat concerned how well the project 
fared with regard to the triple constraint. However, users and 
customers are mostly concerned about the deliverable the 
project produces at the end of the day. Consideration such as 
‘fit for use’ or usability are of greater concern at Level 3. Various 
examples exist where the product produced by a project can 
successfully be used by the project’s customers and has yet 
failed on Level 1 and Level 2 criteria (Marnewick 2016; Serra & 
Kunc 2015). If a project meets the customer’s specifications, the 
project can be termed a success on Level 3. Product success 
would then be achieved. 
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Project success on Level 4 is determined by realised benefits 
provided subsequent to project completion. Should the benefits 
promised in the initial business case actually accrue or realise as 
a direct result of a completed project, then the project would 
be a success. Unfortunately, these benefits do not immediately 
become apparent as soon as the project is completed (Marnewick 
2013b). These benefits would only start to become a reality when 
the product delivered by the project has been fully operationalised 
and integrated in the organisation. Only after an indeterminate 
period of time, and after careful observation and measurement, 
would the direct impact of the deliverable become known. 


Ultimately, Level 4 project success is determined by whether 
or not business goals have been achieved or not through 
the successful completion of a project. What one has to bear 
in mind is the fact that certain unintended consequences or 
benefits may result after the integration of a project product in 
the organisation. Where it may be difficult to point to a specific 
project to indicate what impact it had on achieving business goals, 
it may be simpler to determine where a group of strategically 
similar projects have had such an impact. This may be done in 
the form of prudent programme management where control and 
coordination could be achieved between projects that are aimed 
at achieving a particular business objective. In organisations 
where no programme management discipline exists, it will have 
to make do with strong project management reporting. 


Level 5 project success is externally focused in that strategic 
success is to result because of successful project delivery. These 
concerns are focused on whether the organisation’s position shows 
improvement with regard to investors, the competition and the 
market in general. This level of success may be extraordinarily 
difficult to attribute to any single project. Therefore, portfolio 
management may be better suited as this is an attempt to aggregate 
all project outcomes throughout the organisation to determine the 
strategic success of the project discipline in the organisation. This 
will obviously only be of any meaning if an effort was made to align 
all projects to the organisation’s strategic intent. 
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Strategic level: Portfolio management 
v Level 5: Strategic success for external stakeholders 
v Level 4: Business success for internal business stakeholders 
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Tactical level: Programme management 
v Level 4: Business success for internal business stakeholders 
v Level 3: Deliverable success for user/clients 
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Operational level: Project management 

v Level 3: Deliverable success for user/clients 

v Level 2: Project management success for stakeholders 
v Level 1: Process success for technical stakeholders 
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FIGURE 2.3: Project outcome and portfolio, programme and project management. 


Organisational benefit 


Product & 
project success 


Mapping these perspectives to the traditional three 
organisational levels as well as project, programme and portfolio 
management provides the following view in Figure 2.3. 


Some overlap may exist on Level 3 and Level 4. Deliverable 
success may form part of project or programme management, 
depending on the structure of the organisation. Level 4 is 
most often found under portfolio management (Jenner 2016) 
of the organisation but may also be found under programme 
management (Serra & Kunc 2015). These adaptations will have 
to be considered in organisations that do not have a programme 
management office for lack of need. 
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E Success and failure 


When one is set to lose a contest one was almost certain to 
win through bad judgment and mistakes, one is said to have 
snatched defeat from the jaws of victory. In project management, 
there seem to be many avenues to attain success, given the five 
different available perspectives. Additionally, we know what 
causes projects to fail and to succeed, yet we continue to reach 
out feverishly towards defeat. 


Bannerman (2008) takes great pains to clarify that the 
five levels of project success are not related in an aggregated 
manner. He indicated that process success does not imply 
project management success. A project that was successfully 
completed in scope, time and budget does not guarantee that 
the deliverable will be accepted or useful to the customer. 
A product regarded as useful by the customer does not imply 
that business objectives will be met. Achieving business 
objectives does not imply that the organisation will be 
strategically successful. Clearly success is dependent on a 
specific stakeholder’s perception. 


Does one need to be successful on all five levels before a 
project can be deemed successful? Luckily this seems not to be 
the case as it would be a Herculean task. The technical project 
team member responsible for a specific process on Level 1 can 
in no way be held responsible for the outcome on strategic 
success in Level 5. However, is the executive board dependent 
on these technical processes being completed successfully in 
order to attain strategic success in the long term? The research 
determines it need not necessarily be so. 


We are left with a conundrum. Vast bodies of literature 
extoll the virtues of proper project, programme and 
portfolio management. Each academic work enumerates the 
seemingly countless processes, procedures, inputs and outputs 
for each activity. Is it all for nought when the organisational 
leaders above the project manager’s pay grade are unaffected 
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by their successes and failures? Why is there such an emphasis 
on completing projects successfully when there is little ultimate 
significance in the high levels of the strategic hierarchy? 


It seems that project management shares certain principles 
with alchemy. The alchemists of yore attempted to transform 
lead into gold. They never attempted to create gold from 
nothing. The same may be true in project management. The 
technical processes on Level 1 needed to produce a ‘substance’ 
that project managers could use to transform into another 
‘substance’ in Level 2. This new substance takes on the form 
of a project outcome: success or failure. The individuals in 
Level 3 need to create this ‘project management substance’ 
and create a product that could be either a success or a 
failure. The Level 4 alchemist needs to transform this ‘oroduct 
substance’ into some sort of business benefit and that must be 
transformed again into strategic success in Level 5. 


Therefore, two items are required in order to perform ‘project 
management alchemy’: substance and alignment, success is 
not necessarily required. The substance is the output from each 
level of project success. In order to guide the transformation 
process to ultimately deliver project management ‘gold’ in the 
form of strategic success, some sort of strategic alignment is 
required. 


Without some sort of outcome from the previous levels, 
it would not be possible to create an outcome that could be 
ultimately usable in Level 5. And even if a high-quality outcome 
is delivered at lower levels, if it cannot be taken to ultimately 
further strategic objectives, the effort is futile. 


Evidently, the terms ‘success and failure’ only have meaning 
on Level 5 as they relate to ultimate project outcomes. On 
Level 1 to Level 4, ‘success and failure’ only serve as a basis for 
organisational governance to ensure that resources are used 
appropriately in order to deliver a ‘substance’ of higher quality 
that could more easily be transformed in the next level. 
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E Outcome influencers 


What would enablers and inhibitors of success be at each level in 

this ‘process’ view? The discussion focuses on the three grouping 

of success as identified by Bannerman (2008): 

1. Project success including technical process and project 
management success. 

2. Product success. 

3. Organisational benefit including benefits realisation and 
strategic success. 


Project success 


The vast body of research focuses its attention on the mechanism 
and processes of project management and what these contribute 
to delivering successful projects. The main enablers of success 
in this section primarily deal with the skills and knowledge of 
project managers. 


Regarding specific technical processes, the main aspects 
that project managers and their team members need to focus 
on is in risk management and change control (Marnewick 
& Erasmus 2014). Of these two, risk management is the 
knowledge area in the PMBOK® Guide that is the least matured 
in practice: 


e Proper risk management practices increase the quality of 
project management in that eventualities are planned for in 
budget, schedule and scope. This would decrease variances in 
the triple constraint, resulting in a greater chance of project 
management success. 

e When certain parameters of the project are changed, 
depending on whether specific technical processes are 
completed correctly, the knock-on effect impacts the triple 
baseline constraint. Change control must be present as change 
is a given in the vast majority of projects. The impact of 
uncontrolled changes is impossible to fully quantify. The effect 
on the project, however, is devastating. 
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The skill that most project managers agree is the greatest 
contributor to success is communication with the project team 
(Marnewick et al. 2016a, 2016b; Monteiro de Carvalho 2013). This 
stands to reason as all interaction in a project concerns the flow 
of accurate information. 


Inhibitors to success would include the antecedents of the 
contributors to project success as discussed. However, when 
organisational leaders recognise the need for additional training 
something very counterintuitive happens. Project managers who 
are sent for certification courses seem to develop a reduced 
ability to deliver projects successfully once they are certified in 
a formal project methodology (Joseph et al. 2014). The reasons 
behind this are unclear, but as it stands, formal certification 
seems to be an inhibitor of project success. 


Another great inhibitor to project success is an organisational 
culture that does not allow for or value prudent project 
management practices (Mir & Pinnington 2014; Rosemann 
& Vom Brocke 2015). This would include undue pressure on 
project managers to shorten the planning phase of their project 
in order to get to execution more rapidly. This rush may leave 
many risks and challenges unidentified, resulting in chaos during 
execution. 


Product success 


Product success implies the user and/or customer have their 
needs met through the project deliverable, regardless of how it 
came into their hands (Bannerman 2008). The greatest success 
enabler here is effective communication with stakeholders, more 
specifically between the project team and the user or customer 
(Barclay 2015; Davis 2014). This is to ensure that correct client 
specifications are used in designing the product or service to 
be delivered. This entails that proper requirements management 
takes place. Regular customer feedback is required to ensure 
that all stated needs are met in the deliverable. 
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Another enabler of product success is the active involvement 
of an individual that could fulfil a customer relations role that 
further facilitates communication. This is especially important 
when project management failure is looming. 


Aninhibitor to product success is, of course, miscommunication 
and changing requirements. It will obviously be much more 
difficult to meet customer requirements should these be in 
flux. Unreasonable customers may also decide not to accept 
the product even if all signed-off requirements are met, but the 
actual product is not what was expected by the customer (Turk, 
France & Rumpe 2014). 


Organisational benefit 


The organisational benefits are achieved as aresult of successfully 
completed projects or programmes in the organisation that 
impart a strategic advantage. 


Benefits realisation is a perspective internal to the organisation 
that could overlap the strategic and tactical organisational levels. 
This perspective takes a longer view of the effect of projects in the 
organisation in that benefits can only accrue after a project has 
been completed. These benefits are not immediately apparent. In 
order to internalise these benefits, the project deliverable needs 
to be integrated into the organisation. This would imply that some 
level of organisational change management must be initiated. This 
process could be illustrated as in Figure 2.4 (Coombs 2015). 


For the implementation of an IS deliverable, operations need to 
be adapted to accept and effectively utilise the new deliverable. 
The premise is that business benefits will only accrue once business 
change has occurred through the use of IT. This seems eminently 
reasonable in an IS context (Whyte, Lindkvist & Jaradat 2016). 


For the implementation of an IS-type deliverable, the following 
main inhibitors to benefits realisation are identified (Coombs 
2015): 
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Inhibitors 


IT enabled operational transformation 


- Business 
Business 
e~ i 
IT change benefits 


FIGURE 2.4: Information technology enabled operational transformation. 


Staff not engaging with new ways of thinking: This speaks 
directly to the difficulty in changing organisational culture 
and the individuals resistance to change. 

Poor design of the new system: Clearly this links to product 
success. A poorly designed product or deliverable will not be 
readily accepted by its intended users. Expected benefits will 
only accrue once these deficiencies are corrected after the 
closure of the project. 

Poor performance of the system: This is another product- 
related metric that would inhibit the use of the system and its 
subsequent realised benefits. 


Here we see a much stronger link between levels of 


project success in Level 3 and Level 4, benefits realisation. The 
results imply that a poor product deliverable could negatively 
impact benefits realisation. A poor quality deliverable in 
Level 3 implies an inhibitor to benefits realisation in Level 4. 
Enablers of benefits realisation include the following: 
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Training in the use of the deliverable. Users cannot immediately 
accept the new deliverable. Initial acceptance would be 
dependent on training and ensuring users and customers are 
used to the new systems. However, this would only account 
for product success on Level 3. Enhancing the chances of 
success at Level 4 requires ongoing training for users to 
use the new system to its fullest potential. A change in 
organisational culture is required in order to sustain the 
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transformation effort and to prevent users from falling back 
into old patterns of behaviour that may have necessitated the 
creation of a new system. 


It seems in benefits realisation that inhibitors are more technically 
oriented, while enablers are more organisationally oriented. It 
would, therefore, be appropriate that transformation activities 
take place under the auspices of an organisational entity that 
is responsible for mapping and tracking benefits. Strategic 
success on Level 5 has an external perspective where all project 
activities, from Level 1 to Level 4, culminate in some impact on 
the market. This is only possible where strategic alignment has 
taken place where all projects are part of a concerted effort to 
support strategy (Gerow, Thatcher & Grover 2015). 


With this lofty goal in mind, it may stand to reason that project 
practitioners have very little to do with strategic impact external 
to the organisation. Instead, very senior members of the board 
tasked with portfolio management are the key role players that 
have to ensure that the organisation’s strategic intent is achieved 
through the support of the entire organisation. The delivery of 
a product through project management methodologies, while 
essential, is only one small part of the entire exercise (Kaiser, El 
Arbi & Ahlemann 2015). 


An enabler of strategic success from a projects perspective 
is a concerted strategic alignment initiative that ensures that all 
projects are selected on their probability of success and envisaged 
contribution to the organisation. Without such an alignment 
effort an impact on the market can still be made, however, the 
degree of impact would be very uncertain. Unexpected benefits 
or issues may arise more frequently in such a case. 


Inhibitors to strategic success may include actions to avoid 
such as failure to establish a clear strategy and frequently 
changing strategy. Both these situations require the entire ship 
that is the organisation to change tack, while all its efforts are 
focused on achieving and supporting a different strategy. 
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External market condition will also influence the degree to 
which the current strategy is effective, if the organisation’s chosen 
strategy has not been developed with this in mind. Inhibitors and 
enablers for the success of Level 5 are much more dependent on 
strategic management thinking than purely project management 
considerations. 


E Conclusion 


How project success and failure is defined depends greatly 
on individual interpretation. When taking the organisational 
perspective, perhaps project management success should be 
viewed on a continuum and not on a binary scale of ‘success’ and 
‘failure’. When drilling down into the details of what technical 
and product success actually imply, lower orders of management 
need to be aware of what metrics are being used to determine 
and track how their scarce resources are being utilised. 


Ultimately, the organisation exists to provide value to its 
shareholders. This is most significantly achieved through 
strategic impacts. However, there is something to be said for 
laying the foundation for such success. Success on lower levels 
of project management in no way guarantees success on higher 
levels. Likewise, failure on lower levels does not guarantee failure 
on higher levels. There is, however, an implication that success 
on lower levels contributes in some way to success on higher 
levels. Failure on lower levels may make success on higher levels 
more difficult, yet not impossible. 


What is important is that an actual deliverable is created that 
can be used to eventually attempt to achieve strategic success 
through strategic alignment. In such a way, the organisation can 
attempt to snatch victory from the jaws of defeat, and not vice 
versa. 


32 


i 
Complexity of 


information system 
projects 


Complexity is a concept which is now more prevalent than 
ever (Derbyshire 2016; Vidal & Marle 2008). Geraldi (2008:4) 
proclaims that ‘mastering complexity is not a new challenge 
but an old challenge that is being increasingly recognized 
and accepted. Project management literature traditionally 
emphasise the success criteria and success factors that are 
necessary to understand project performance (Belassi & Tukel 
1996; Cooke-Davies 2002; Ika 2009; Pinto & Slevin 1987). Project 
management research has evolved over the years to include 
the concept of project complexity (Ahern, Leavy & Byrne 2014; 
Baccarini 1996; Cooke-Davies et al. 2007). The increased focus 
on project complexity is the result of attempts to address 
the fluctuating performance of various projects regardless 
of industry and type. This chapter aims to elaborate on the 
concept of project complexity and constructs which constitute 
project complexity. 


How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Complexity of information 
systems projects’, in The symbiosis between information system project complexity and 
information system project success, pp. 33-61, AOSIS, Cape Town. https://doi.org/10.4102/ 
aosis.2017.itpsc45.03 
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E The concept of project complexity 


Project complexity involves identifying and understanding the 
various intricacies embedded in a project. Baccarini (1996:201) 
introduced project complexity within the context of construction 
projects and argued that project management is ‘associated with 
management of complexity.’ The research of Baccarini (1996) 
subsequently resulted in the development of a conceptual model 
of project complexity. Similarly, Xia and Lee (2004) applied the 
concept of project complexity to IS projects and produced a 
conceptual model for IS project complexity. Similar literature 
works have developed models for project complexity to enlighten 
how projects are understood and perceived. Four key models 
are identified and discussed in the sections that follow. 


Complexity model for new development 
products 


New product development (NPD) projects are commonplace in 

many industries but suffer poor performance with regard to time 

and cost (Kim & Wilemon 2003, 2009). Kim and Wilemon (2003) 

investigated these projects and developed a complexity model 

for NDP projects. They argue that NDP projects consist of several 
functions and technologies which add to the level of complexity. 

Furthermore, the level of complexity faced by functional groups 

varies during projects which influences the ‘complexity curve’ of 

a project (Kim & Wilemon 2003:18). Kim and Wilemon (2003) 

discovered the following sources of complexity: 

e Technological complexities: This source focuses on challenges 
with tasks and uncertainties around technology or a 
technological approach. Component integration and 
technological newness underpin the challenges and 
uncertainties. Component integration addresses the complexity 
of integrating the various technological parts, systems and 
subsystems at the software and hardware level. The aim is to 
integrate all components correctly and ensure the system 
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operates effectively. Alternatively, technological newness 
looks at how new technology can be used to solve technological 
issues. If new technology is not understood, the implementation 
of such technology could be detrimental. This applies to the 
novel use of existing technology and the introduction of 
cutting edge technology. Introducing new technology also 
introduces other complexities such as the requirement of new 
skills and resources for effective exploitation. 

Environmental complexities: The markets in which 
organisations and product developers operate are dynamic as 
they follow a rapid pace and are unpredictable at the best of 
times. These external complexities require organisations to 
process data and information more efficiently to remain 
competitive and relevant in their industries. It is therefore of 
paramount importance to understand market size and growth, 
market variability (e.g. regulatory changes), challenges in 
predicting competitors and weakness in adapting to market 
change. 

Development complexities: Complications and complexity 
around the research and development processes are the core 
of development complexities. Factors underlying research 
and development process complexities include, integration of 
multiple research decisions, predicting effort, money and time 
required for new product development, component 
integration, evaluating process requirements for development, 
identifying and obtaining quality suppliers and management 
of supply chain relationships. 

Marketing complexities: Introducing products into new, 
untapped markets requires organisations to apply new and 
novel marketing skills to penetrate the market. This often 
involves conducting intense market and consumer tests. Risk 
appetite is an indicator of how organisations will approach 
entering a new market. Multiple considerations must be taken 
into account such as customer education regarding the 
product, introducing new distribution channels, understanding 
and managing the needs of a new market, establishing pricing 
policies, developing advertising campaigns, user adaptation 
and capability level as well as incompatible technologies. 
Organisational complexities: The organisational structure 
plays a defining role in rolling out NPDs. NPDs require interaction 
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between multiple business units, departments and employees 
which increases the level of complexity. Education and 
communication strategies must be thought out as these will 
ease the management of organisational complexity. 
Furthermore, effective knowledge management and transfer 
must exist within the organisation as this enables the application 
of new tools, techniques and technologies. Another important 
aspect to organisational complexity is that of forming and 
managing project teams which include multiple specialists. 
Team dynamics such as cultural differences, geographical 
location and competency must also be taken into account. 
Intra-organisational complexities: These complexities arise 
when organisations partner to achieve a common goal and 
pursue NPD projects. The original notion is that collaboration 
will not only mitigate other complexity areas but, in turn, 
generate other new complexities. Similar to organisational 
complexities, intra-organisational complexities consider 
aspects such as degree of formality and/or informality, 
dependency issues, communication and relationship 
management challenges, measuring a collaborator’s 
contribution and distributing outcomes equitably. 


Novelty, Technology, Complexity and 
Pace model 


Shenhar et al. (2016:68) developed the ‘Diamond of Innovation’ 
model as a means to tackle project complexity. The model is 
also referred to as the Novelty, Technology, Complexity and 
Pace (NTCP) model (Frank, Sadeh & Ashkenasi 2011). The model 
focuses on project management style selection by assessing the 
four dimensions of NTCP. The four dimensions are defined as 
follows (Frank et al. 2011): 
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Novelty: The newness of the product is the focus of this 
dimension. Three subdomains underpin the novelty dimension, 
(1) derivative, (2) platform and (3) breakthrough. Derivative 
projects have minor improvements over other products, while a 
new generation of products is developed through platform 
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projects. Innovation projects produce unique and niche products 
which are significantly differentiated in the marketplace. 
Technology: Technology and uncertainty are inseparably 
linked in this dimension as the use of technology introduces 
varying levels of uncertainty. The aim is to reduce the level of 
uncertainty by effectively managing the technology employed 
in a project. Four types of technological projects exist, (1) low 
tech, (2) medium tech, (3) high tech and (4) super high tech. 
The more sophisticated the project, the higher the level of 
uncertainty and complexity. Alternatively, uncertainty also 
determines, amongst other things, duration and scheduling of 
tasks and activities, articulating and defining product 
requirements, planning precision and risk mitigation strategies. 
Complexity: This dimension specifically looks at product 
scope and the interdependencies between various project 
components. Complexity directly influences the level of 
formality by which the project will be managed as well as the 
processes employed. 

Pace: Pace stresses the importance of time goals during a 
project as this will influence the project structure and the level 
of management attention. There are four apparent levels of 
timed goals, (1) regular, (2) fast, (3) time-critical and (4) blitz. 
They follow a progressive scale on haste and importance. 


Project Complexity Model 


The Project Complexity Model (PCM) was developed to 
capture the various dimensions of project complexity (Hass 
2009). The aim of the PCM is to provide a framework to identify 
and analyse complexity elements of a project and facilitate 
decision making amongst the project team. Hass (2009) argues 
that specific project management tools, methods and approaches 
will be determined by which dimensions apply to the project. 
The complexity dimensions within PCM are as follows: 


Strategic importance, political implications and multiple 
stakeholders: It is clear there are three subdomains within this 
dimension. Strategic importance is associated with the level of 
executive support and impact on the mission statement set out 
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within the organisation’s strategy. Political implications relate 
to the internal political landscape of the organisation. Political 
issues are often bureaucratic issues and red tape which hinder 
or inhibit the project from being performed as initially planned. 
If these issues are visible at all levels of management, the project 
becomes increasingly complex to manage. Stakeholders play 
an important role during projects and the higher the number of 
them, the higher the level of project complexity. Multiple 
stakeholder groups introduce communication and coordination 
challenges as well as conflicting expectations. 

Level of organisational change: The dimension looks at how 
the project influences and contributes to organisational 
change. Less complex projects have minimal influences such 
as impacting one department, business process or IS. Highly 
complex projects have widespread influences when the entire 
organisation is impacted including internal business units, 
multiple business processes, external joint ventures and 
information systems. Inevitably, the organisation has to 
transform as a result of a highly complex project. 

Level of commercial change: Commercial change pertains to 
how the organisation adapts and changes the way they interact 
within their industry, including activities such as advertising, 
marketing and collaboration. The level of project complexity 
directly influences how the organisation implements commercial 
change. 

Risks, dependencies and external constraints: Risk increases as 
the level of complexity increases. High risk projects carry 
increased risk with regard to the above-mentioned dimensions. 
Projects are always influenced by internal and external factors. 
Dependencies assess the relationship between the various 
factors as well as the impact they have on one another. Project 
integration efforts are also associated with dependencies as 
challenging integrations are often caused by large-scale projects 
where multiple elements must be integrated to realise the 
project’s goals. External constraints relate to regulatory 
requirements within an industry or sector. Operating within a 
familiar regulatory environment implies less complexity, whereas 
highly regulated environments introduce multiple complexities 
when embarking on a new, novel project such as NPDs. 
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Level of IT complexity: Information technology is a powerful 
tool to implement and be used in projects. This dimension 
determines what technology is used for any project type. 
Similar to the NPD model, existing and understood technologies 
traditionally lead to less complex projects. While innovation 
may be the key, the usage of unproven and immature 
technology creates complexity where specialist skill sets are 
required from external vendors. 


Information systems development 
projects complexity model 


The previous models have approached project complexity at a 
generic level. The information system development project (ISDP) 
complexity model was specifically developed for IS projects as 
they ‘are inherently complex because they deal not only with 
technological issues but with organizational factors largely 
beyond the project team’s control’ (Xia & Lee 2004:70). Xia and 
Lee (2004) dissect ISDP complexity into four components: 


Structural organisational complexity: A number of elements 
exist within this component. The level of project manager 
control over resources is the most important element as lack of 
control implies that the project is driven by other individuals 
who are not actively and continuously involved in the project. 
User support is the second element. IS projects preferably need 
continuous user support and feedback to ensure the output is 
a solution which the users need. Insufficient staffing is the third 
element identified for structural organisational complexity. The 
project cannot meet simple goals such as time and cost if 
insufficient staff exists. The fourth element focuses on the 
specialised staff and skills required during IS projects. A 
deficiency of such staff will have detrimental effects on all IS 
project types. The final element, insufficient top management 
support, assesses how much support is garnered from senior 
management, such as the project sponsor. IS projects cannot 
be correctly aligned to organisational strategy if top 
management support is lacklustre or non-existent. 
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Structural IT complexity: Emphasis is placed on more technical 
elements within structural IT complexity. Firstly, the 
involvement of multiple user units influences this complexity 
component as the different users will have different 
perspectives and needs. Cross-functional teams are an 
inevitable prerequisite for IS projects. The second element 
assesses what level of cross-functionality is apparent as 
various internal and external team members are required to 
perform the project. Multiple software environments are the 
next element within the structural IT complexity component. 
IS projects often span various software environments that 
further influence how the project is developed and installed. 
The next element focuses on multiple technology platforms as 
IS projects use a wide range of technologies to realise the 
project’s goal. The inclusion of multiple technologies implies 
that knowledge and skill are required to implement the 
technologies effectively. This also directly relates to the next 
element of integration with other systems as compatibility of 
technology platforms and software environment come to the 
fore. Enterprise-wide IS projects, for example, require full 
integration across all systems and platforms to ensure the 
users’ needs are met. The final element addresses the 
complexity of multiple contractors and vendors. Outsourced 
interventions during IS projects are commonplace as the 
contractors and vendors assist with the implementation of the 
project. Communication and collaboration must be effectively 
managed to ensure the project delivers as initially proposed. 

Dynamic organisational complexity: This complexity component 
places emphasis on pattern and rate of change during ISDPs. 
Change in business processes is the first area of assessment as 
IS projects introduce new ways of performing business tasks 
and thus re-engineer business processes. Frequency of 
information change must be managed as the users’ information 
needs change rapidly during IS projects. Patterns regarding 
information change must be identified and understood to ensure 
the correct information is relayed to users at all times. Similar to 
changes in business processes, how the processes are changed 
from a user’s perspective is important to understand given that 
they are the ones most likely to use the system for day-to-day 
activities. Certain IS projects also change the structure of the 
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organisation itself through the change and/or introduction of 
new business processes and functions. Alternatively, a different 
view is how a constantly changing organisational structure 
influences the project itself. Organisations which rapidly change 
structure during an IS project bring about added complexities 
to the execution of the project. 

e Dynamic IT complexity: The IT infrastructure changes 
throughout its lifetime in an organisation. IT infrastructures 
can change rapidly given the rapid rate of development within 
IT. Constant changes in infrastructure add technical 
complexities to IS projects as it becomes difficult to make 
decisions when technological uncertainty arises. Furthermore, 
there must be careful cognisance of the IT architecture as this 
often dictates and influences structural IT complexities. 
Software development is a high-paced environment with rapid 
movement. Programming languages and tools are constantly 
evolving to enhance IS functionality. Rapid change in languages 
and tools must be considered at all times as these influence 
how the project is executed, implemented and tested. 


The above-mentioned project complexity models provide an 
overview of project complexity and its subsequent components. 
The following section takes an in-depth look at what exactly 
constitutes project complexity and applies it to IS projects. 


E Constituents of project complexity 


There are various views on project complexity and no clear 
definition or understanding of what exactly constitutes this 
phenomenon. This section goes beyond the project complexity 
models and analyses in depth how multiple publications 
conceptualise project complexity. Textual analysis was performed 
through content analysis to identify the underlying components 
of project complexity (Flick 2014; Martens & Carvalho in press; 
Pade, Mallinson & Sewry 2008). The following research protocol 
was applied when conducting the content analysis (Schön, 
Thomaschewski & Escalona 2017). Key concepts were first 
identified and articulated to develop search terms, for example 
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‘project complexity, project management complexity, complex 
project management.’ Six databases were targeted as they were 
identified as the primary databases which cover the key concepts. 
Forward and backward sampling were used to enhance content 
availability. Forward snowballing searches literature which has 
cited the literature in question, while backward snowballing 
searches the reference list for literature (Badampudi, Wohlin & 
Petersen 2015; Jalali & Wohlin 2012; Schön et al. 2017). The final 
step involved manual examination of literature sources to ensure 
the concepts were well represented and articulated (Asher 2013; 
Dube & Marnewick 2016; Schön et al. 2017). 


Five underlying components were identified from the content 
analysis, (1) organisational complexity, (2) technical complexity, 
(3) environmental complexity, (4) uncertainty and (5) dynamics 
(Baccarini 1996; Bakhshi, Ireland & Gorod 2016; Bosch-Rekveldt 
et al. 2011; Dunovié, Radujkovié & Skreb 2014; Floricel, Michela 
& Piperca 2016; Geraldi, Maylor & Williams 2011; Remington & 
Pollack 2007; Senescu, Aranda-Mena & Haymaker 2013; Vidal & 
Marle 2008; Williams 1999). An overview of project complexity 
components is illustrated in Figure 3.1. Each component 
contributes to the level of project complexity to some degree. 
The identification of the components is, however, only the first 
step as more investigation is required to illuminate what exactly 
these components consist of. The content analysis revealed that 
each component consists of various elements which, in turn, 
consist of various features. The following section delves deeper 
into each component and their applicable elements and features. 


Organisational complexity 


Projects are generally seen as ‘temporary endeavors’ (Schwalbe 
2013:4) within an isolated context, but this is far from reality as 
they have a greater role within the organisational context. The 
organisational context implies that all projects are influenced by 
organisational aspects which are rarely taken into account during 
all projects and especially IS projects. This section presents the 
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Technical 
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Project 
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FIGURE 3.1: Overview of the components of project complexity (derived from content 
analysis). 


multiple elements and features which contribute to project 
complexity: 


1. 


The first element of organisational complexity centres on 
vertical differentiation (Baccarini 1996). Vertical 
differentiation deals with the formal structure of the 
organisation, that is, whether the organisation has, amongst 
others, a functional, matrix or flat structure. Each structure 
has varying views on hierarchy as a functional structure has 
strict levels of command, whereas a flat structure has no 
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levels of command effectively (Hobday 2000). The varying 
structures influence project execution particularly as 
communication and collaboration is different depending on 
the structure (Geraldi et al. 2011). 


. Horizontal differentiation is the second element within 


organisational complexity (Baccarini 1996). Two features form 
the foundation of this element, that is organisational units and 
task structure. Regardless of structure, each organisation has 
organisational units which serve a particular purpose. The 
number of units varies in each organisation and must therefore 
be taken into account from a project complexity perspective 
(Dunovié et al. 2014). Task structure places focus on how 
project tasks are divided and distributed to the relevant 
responsible parties (Lu et al. 2015). This is particularly 
important during the planning stage of a project, and thus 
particular attention should be paid to defining tasks as best as 
possible. Tasks are, however, not set in stone and are prone to 
change during the project. 


. Organisational complexity’s third element is that of size, which 


consists of multiple features: 


e Project duration: This feature relates to the constraint 
of time (Bosch-Rekveldt et al. 2011). Time is commonly 
used as a criterion for determining project success. Its 
representation within project complexity is arguably 
less vital given the sheer number of other complexity 
elements and features to consider. Nevertheless, the 
inclusion of duration is important as all projects have a 
time goal in which they want to be operational. With 
regard to IS projects, time is an important feature to 
consider as these projects are launched to achieve or 
maintain competitive advantage. 

e Project method and tool variety: The project 
management landscape is awash with various methods 
and tools. Information system projects, for example, are 
more commonly adopting the philosophy of Agile as a 
new approach to deliver projects (Chan & Thong 2009). 
The Agile landscape, however, is not simple as there 
are multiple methods which can be chosen and used, for 
example scrum, extreme programming, rapid application 
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development and dynamic systems development 
methods to name a few. Selecting from multiple methods 
can become difficult especially when there is a lack of 
understanding and knowledge amongst the project team 
regarding the details of the method. Methods cannot be 
adopted based on ‘buzzword’ status as this negates any 
potential benefit from adopting the method(s). 

Capital expenditure: This feature relates to the 
constraint of cost (Bosch-Rekveldt et al. 2011). Significant 
sums of money are spent on IS projects, which implies 
their strategic importance to many organisations 
(Joseph & Marnewick 2014). Cost is therefore an 
important feature as failed projects do occur at the cost 
of millions and reflect badly on the implementation of 
other IS projects. 

Work hours: Many hours are spent on projects of all 
types to realise the project and business goals (Thomas 
& Mengel 2008). The number of work hours is determined 
by the scale of the project as well as the task structure. 
Work hours should be meticulously managed during 
large-scale IS projects particularly as there are a 
multitude of interdependencies. Moreover, the number 
of work hours is heavily influenced by IS projects which 
span geographical regions. 

Project team: The size of a project team directly 
influences project complexity (Bosch-Rekveldt et al. 
2011). Large teams include individuals from multiple 
departments, thus introducing heightened levels of 
complexity. The management of large teams can become 
cumbersome for project managers as Communication 
and collaboration breakdowns are highly likely. 

Site area: The physical size of the project site(s) is 
important to identify as this will influence certain aspects 
of the project (Bosch-Rekveldt et al. 2011). While the 
initial plans dictate project activities amongst other 
things, careful attention must be paid to how the physical 
attributes of the site will influence these activities. 
Number of locations: As mentioned previously, 
geographically dispersed projects are commonplace 
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within multinational organisations particularly. These 
dispersed projects affect project complexities such as 
logistics where travel and access must be considered 
when executing the project (Padalkar & Gopinath 2016). 
IS projects often implement systems which span 
offices across the globe and thus should be fully 
integrated. Full integration, therefore, requires a robust 
understanding of the locations where the system must 
function. 


4. The element of resources emphasises tangible and intangible 
resources required for any given project. The following 
features must be considered for the fourth element of 
organisational complexity: 


46 


Project drive: Strategic goals underpin the need and 
execution of IS projects. Project drive, therefore, pertains 
to the level of strategic importance and support required 
for a project (Milis & Mercken 2002). Inadequate support 
implies that the project will not be aligned to the overall 
goals of the organisation and thus not deliver the 
benefits as initially stipulated. The drive of the project 
must therefore be sound and understood by all parties 
involved to ensure it realises the greater strategic goal. 
Resources and skills availability: Different projects 
require different skills and resources even if the projects 
seem similar on paper (Baccarini 1996). Specific 
resources with regard to raw materials must be clearly 
identified and acquired to implement the project 
correctly. Project complexity is aggravated when 
projects such as IS projects require very specialised 
skills which need to be sourced externally. External 
vendors are often brought in to provide these skills, 
which add other complexity layers such as project team 
composition, capital expenditure and work hours. 

Experience with parties involved: Stakeholder 
management and its importance are documented in 
project management standards such as the PMBOK® 
Guide (Project Management Institute 2013). Experience 
withinvolved stakeholders and parties creates somewhat 
of a more predictable landscape during a project as 
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there is a better understanding of the parties involved 
(Bosch-Rekveldt et al. 2011). Unknown parties require 
extra effort from the project manager and team as they 
will have to engage more to ensure they perform as 
required. 

Health, safety, security and environment (HSSE) 
awareness: HSSE is traditionally associated with 
construction projects and not IS projects. HSSE should, 
however, be applied to all projects as there are national 
regulations overseeing the implementation of HSSE 
(Bosch-Rekveldt et al. 2011). Project managers in 
particular should be aware of all HSSE concerns in a 
project as this will mitigate any possible litigation arising 
from regulatory bodies. 

Interfaces between disciplines: Cross-disciplinary 
integration is inevitable in projects as specialists from 
various fields are required to execute certain tasks 
(Baccarini 1996). The interfaces or interactions between 
the various disciplines must be identified and managed 
accordingly as this influences other areas such as skills 
availability, works hours, capital expenditure and project 
duration, to name a few. The more disciplines required 
for the project, the higher the level of project complexity. 
Financial resources: Projects cannot be executed 
without sufficient availability of financial resources 
(Killen & Kjaer 2012). Financial resources, however, 
should be managed in a sustainable manner to ensure 
they are distributed correctly and not squandered on 
ineffective tasks and resources. As mentioned before, IS 
projects require significant expenditure but do not 
always translate these financial resources into 
organisational benefits. 

Contract types: Resources are procured from various 
suppliers, whether internal or external. Regardless, 
contracts are negotiated and signed to ensure the required 
resources are available for a project. Contractual 
agreements and arrangements often become intricate and 
complex and thus add to the complexity of a project 
(Bosch-Rekveldt et al. 2011). 
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Intricacies relating to the project team are the fifth element 
within the organisational complexity and consist of the 
following features: 


Different nationalities: Projects do not need to be 
geographically dispersed to have the complexity of 
different nationalities working on the project. The key to 
different nationalities is that of understanding national 
cultures and ensuring that they are understood and not 
offended (Geraldi et al. 2011). Productive project teams 
understand their boundaries and limitations when 
working with different nationalities. Furthermore, it is the 
responsibility of the project manager to manage these 
cultural relations and mitigate any possible conflicts. 
Different languages: Different nationalities also 
introduce difficulties associated with language (Bosch- 
Rekveldt et al. 2011). Language barriers imply that team 
members and stakeholders cannot understand one 
another enough to effectively execute the project. 
Language issues also arise when the main language 
used for a project is not the first language for some 
parties involved. It is therefore important that this social 
aspect is identified early on and possibly before the 
project initiates as this will ensure the project does not 
experience difficulties during the project. 

Joint-venture cooperation: Many projects are executed 
as a joint venture between two or more organisations 
(Geraldi & Adlbrecht 2007). The roles and responsibilities 
of each organisation must be clearly articulated before 
project initiation and planning as they will dictate the 
way forward for the project. Organisations could 
perform the same tasks differently as they have varying 
management styles and structures. Cooperation 
between the parties involved should therefore be 
documented and made transparent to all to ensure a 
common understanding between all parties. 

Office hour overlaps: Overlapping of office hours 
primarily occurs in projects which are executed in 
multiple time zones. The project manager and team 
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must be cognisant that certain tasks and activities can 
only occur when there is office hour overlap between 
time zones (Geraldi et al. 2011). On the other hand, 
there could be instances where overlapping hours 
could be minimal thus creating a heightened level of 
complexity. It is therefore imperative that there is a clear 
understanding amongst those operating within different 
hours to ensure effective communication occurs during 
the project. 


6. The sixth element focuses on two features of trust, that is trust 
within the project team and in the contractor (Bosch-Rekveldt 
et al. 2011). The project team must operate as efficiently as 
possible to ensure they deliver what is expected by the business. 
The team would thus work best when trust is apparent between 
all those involved (Geraldi & Adlbrecht 2007). Moreover, this 
relates to the feature of experience with involved parties as 
more experiences can arguably translate to increased trust to 
perform certain tasks and activities. Similarly, trust must exist 
with the contractor or outside vendor (Geraldi et al. 2011). 
Trust in a contractor does not only entail trusting that they 
play their part but, more importantly, that they provide the 
required skills and knowledge needed for executing the 
project. Trust is a social paradigm which is more focused on 
soft aspects such as people management than on hard aspects 
such as technical requirements management. 

7. Risk is the seventh element within organisational complexity 
where emphasis is placed on organisational risk specifically 
(Bosch-Rekveldt et al. 2011). Thamhain (2013) asserts that there 
are four categories of risk, (1) no impact on project performance, 
(2) actual impact on project tasks and subsystems, (3) actual 
impact on project performance and (4) actual impact on project 
and enterprise performance. Category four of risk therefore 
implies that the entire organisational performance is at 
stake if project risk is not addressed. Risk can, however, be 
mitigated through continuous stakeholder communication and 
collaboration (Floricel et al. 2016). 

8. Projects are fraught with interdependencies which further 
complicate matters. Interdependencies are thus the eighth and 
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final element of organisational complexity. Interdependencies 
consist of the following features: 


Environmental dependencies: These span the internal 
and external operational environment in which the 
organisation operates (Vidal & Marle 2008). The 
implication is that both environments must be surveyed 
and understood as best as possible to ensure the project 
is not negatively affected by underestimating its 
environmental dependencies. 

Resource sharing: Organisations execute multiple 
projects at once and thus share resources between them 
(Vidal, Marle & Bocquet 2011). Furthermore, the same 
resources are often shared with day-to-day activities 
which further escalate project complexity. Resources are 
not infinite and must be managed accordingly between 
all relevant parties. It is predominantly the project 
manager’s responsibility to ensure that required resources 
are available when needed and to liaise with other project 
managers for effective resource management. 

Schedule dependencies: Similar to resource sharing, 
schedule dependencies require the same attention as 
certain project activities, and tasks are conducted 
sequentially while other tasks are run in parallel. A lack 
of schedule dependency understanding inevitably 
introduces increased complexity which could lead to 
chaos within a project and subsequent project failure 
(Baccarini 1996). 

Interconnectivity and feedback loops in task and project 
networks: Communication is at the heart of this feature 
as the emphasis is on feedback loops between the parties 
involved (Vidal et al. 2011). There must be a clear level of 
transparency amongst all stakeholders as this enlightens 
and reassures what tasks have been performed as well as 
the status of the task. 

Dependencies between actors: All project stakeholders 
have some form of dependency on one another (Padalkar 
& Gopinath 2016). Any project which is not cognisant of 
that will perform poorly and not as intended. It is, 
however, important that there are not an exorbitant 
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number of communication and collaboration channels 
and platforms as this will compromise and distort any 
work being done. 

Information systems dependencies: Various information 
systems are used as a source of information during a 
project (Baccarini 1996). The relationship between these 
systems is important as not all systems provide the 
same functionality. Furthermore, the technical nature of 
information systems is important to understand to 
ensure the most benefit is gained from them. There is 
arguably alink between this element and skills availability 
as the use of these information systems often requires 
specialised skills to extract the maximum benefit. 
Objective dependencies: Each project has goals which 
are linked to greater strategic goals. The relationship 
between them is important as there should be clear 
and strict alignment between the project and strategic 
goals (Vidal et al. 2011). Furthermore, the relationship 
between the various project goals must be clearly 
articulated as they work in tandem to realise strategic 
goals. 

Process interdependencies: Project management is a 
process-based activity where each process serves a 
function and feeds into another. Alternatively, projects 
operate within daily business processes, and thus the 
relationship between project and business processes 
must be identified and managed accordingly to reduce 
increased project complexity (Padalkar & Gopinath 
2016). 

Stakeholder interrelations: Both internal and external 
stakeholders interact during a project’s lifecycle. These 
interactions and interrelations directly influence the 
level of project complexity as information and resources 
are shared between these stakeholders to realise the 
project’s goal (Baccarini 1996). 

Team cooperation and communication: There is constant 
reference to communication and cooperation in multiple 
project complexity features, especially with regard to the 
project team (Geraldi & Adlbrecht 2007). Internal feedback 
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loops amongst team members is critical to ensure the 
project delivers as expected and project complexity is 
managed effectively. 


Technical complexity 


Technical complexity originated from technological complexity 
where the emphasis was on technology and its intricacies 
(Baccarini 1996; Brown 2008). Over time, however, technical 
complexity expanded to include elements and features which 
place more emphasis on detailed aspects of a project (Bosch- 
Rekveldt et al. 2011; Floricel et al. 2016). The following elements 
constitute technical complexity: 


1. 
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Differentiation regarding inputs and outputs is the first 
element of technical complexity (Green 2004). Project 
processes and activities have various inputs and outputs 
during the project’s lifecycle. The number and diversity of 
inputs and outputs must be considered under the greater 
umbrella of project complexity (Baccarini 1996). A large 
number of inputs and outputs implies that there are multiple 
interconnected parts which must be managed accordingly in 
a process-driven environment such as project management. 
On the other hand, the diversity and scale of the inputs and 
outputs play a role in the level of importance of each 
overarching process in which they operate. Project complexity 
is therefore influenced by the number and diversity of inputs 
and outputs as they underpin the project management 
process itself. 


. The second element of technical complexity focuses on 


project goals (Bosch-Rekveldt et al. 2011). Project goals 
have been referred to in the project drive and objective 
dependencies features in organisational complexity and, 
again, in technical complexity which reiterates the 
importance of understanding the project goal dynamic. The 
first feature within project goals is that of the number of 
goals. The more goals there are to achieve the more complex 
the project becomes (Gallstedt 2003). This leads directly to 
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the second feature, goal alignment, where the goals should 
be aligned to one another and the strategic goals (Geraldi & 
Adlbrecht 2007). Project goals which contradict one another 
imply that the project is destined for failure as there is no 
common ground or vision on what the project must achieve. 
Goal alignment subsequently leads to the third feature of 
goal clarity. Goals which are understood and transparent 
to all the stakeholders are the key to the successful delivery 
of a project (Shenhar, Levy & Dvir 1997). Conflict and 
contradicting goals should be avoided at all costs as 
previously mentioned. 

. Scope is the third element and focuses on scale of scope and 
quality of requirements (Bosch-Rekveldt et al. 2011; Floricel 
et al. 2016). The requirements dictate what a project should 
achieve once they are completed. The scale of scope therefore 
refers to what requirements must be successfully implemented 
for the project to deliver business benefits (Vidal & Marle 
2008). On the other hand, the quality of requirements is more 
specific as it looks at whether the documented requirements 
are well detailed and understood (Floricel et al. 2016). Quality 
requirements should be correct, Unambiguous, complete, 
consistent, prioritised for importance and/or stability, be 
verifiable, modifiable and traceable (Marnewick 2013). The 
omission of any of these attributes implies that the level of 
project complexity will be raised and that the project will not 
deliver as initially planned. 

. Technical complexities relating to project tasks is the fourth 
element to consider. Firstly, the number of tasks plays an 
influential role as projects with many interconnected tasks 
are more cumbersome to manage, as discussed in the 
interdependencies element of organisational complexity 
(Heaslip 2015). The number of tasks also relates to the 
number of inputs and outputs as certain tasks act as inputs 
while others act as outputs. Secondly, the variety of tasks 
speaks to the varying difficulty and speciality of tasks as not 
all tasks are equal and some are more specialised than others 
(Senescu et al. 2013). Thirdly and finally is the feature of 
conflicting norms and standards (Bosch-Rekveldt et al. 
2011). This feature focuses on the misunderstanding of 
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organisational standards and procedures other than project 
management ones. Although organisations strive to achieve 
congruence amongst all standards there are spaces where 
this is not the case. It is essential to discuss any conflicting 
standards and decide on the best way forward before the 
project is adversely affected. 

5. Experience within technical complexity refers to technological 
experience specifically. Experience with regard to new and 
current technology is the focus of this element. New 
technology is often punted as performing the same tasks 
better and more efficiently, but the problem arises when the 
new technology needs to be implemented as part of the 
project (Tatikonda & Rosenthal 2000). A barrier to adopting 
new technology is that of understanding as the project team 
should understand the technology and how it will influence 
the entire project if implemented. Experience with technology 
is therefore important as the more experienced the team is 
with the technology, the more likely they will be able to 
implement it correctly (Tatikonda & Rosenthal 2000). Projects 
which boldly implement new technology often suffer many 
side effects such as integration issues and lacklustre user 
acceptance as the technology is not thoroughly investigated 
and understood. 

6. The final element is that of technical risk where the focus is on 
technological risks (Deutsch 1991). Technological risks include, 
amongst others, what technology will be used, will the 
technology integrate correctly, availability of technology and 
whether technology will be obsolete before project completion 
(Ahmed 2012:343). Furthermore, the frequency and impact of 
these risks must be taken into account to ensure the project is 
not adversely affected. 


Environmental complexity 


Organisations operate within various industries, and the projects 
they initiate are influenced by the dynamics of these environments 
(Bosch-Rekveldt et al. 2011). This project complexity component 
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illustrates that projects are not entirely isolated 


endeavours as traditionally believed. 


1. The first element focuses on stakeholders specifically and 
their intricate role in projects. The stakeholder element 
consists of various features: 


Number of stakeholders: Stakeholder numbers have 
a positive relationship with the level of project 
complexity, that is, the more stakeholders there are, the 
more complex the project becomes (Vidal & Marle 
2008). Management of all stakeholders is important to 
ensure there is consistent understanding by all the 
participants. 

Varying stakeholders’ perspectives: Management of 
stakeholders must also include an awareness of varying 
perspectives, that is each stakeholder views the project 
and its status in a different light (Bosch-Rekveldt et al. 
2011). For example, senior management views the 
project in a strategic light, while operational staff 
assess the project with regard to how it will influence 
their daily activities. 

Political influence: This can be viewed from both an 
internal and an external perspective (Floricel et al. 2016). 
The internal perspective looks at political influence 
within the organisation, such as when the project team 
is pushed by senior management to implement the 
project as soon as possible for strategic goal realisation. 
Alternatively, external political influences focus on 
politics at the national and international level (Vidal & 
Marle 2008). This is often through regulation and 
legislation by which the organisation and project must 
abide. 

Internal support: Projects must benefit from some 
form of internal support for them to be successfully 
implemented (Geraldi & Adlbrecht 2007). Senior 
management in particular, should be heavily 
involved in and continuously support the project 
throughout its lifecycle. Lack of support has often 


55 


Complexity of information system projects 


2. 


56 


reared its head as a key factor influencing project 
failure (Hastie & Wojewoda 2015; Joseph, Erasmus & 
Marnewick 2014). 

e Required local content: Many nations require 
organisations to make use of local content and resources 
as a means to ensure the organisation contributes to 
economic growth and does not merely exploit national 
resources. 


The second element of environmental complexity centres 
on the location of a project. The first feature deals 
with interference with an existing site where any possible 
interference with the project site is identified and understood 
(Bosch-Rekveldt et al. 2011). Once identified and understood, 
these interferences can be managed accordingly to avoid 
adverse impacts on the project. Weather conditions are the 
second feature within the location element. Projects operate 
in geographically dispersed regions, and the effect the 
weather has on the projects must be analysed beforehand 
as weather can have a detrimental effect during project 
execution particularly (Sohi et al. 2016). Alongside weather is 
the remoteness of the location where some project locations 
are isolated from business hubs and thus require special 
attention regarding resources and logistics (Nguyen et al. 
2015). The final feature focusses on country experience. 
Similar to experience with involved parties in organisational 
complexity, organisations which initiate projects in regions of 
which they have experience are more likely to have fewer 
hurdles than when introducing a project in a completely new 
region (Floricel et al. 2016). 


. Market condition is the third element. A more specific 


political influence of internal strategic pressure is the first 
feature within market conditions (Bosch-Rekveldt et al. 
2011). The project manager and team are prone to increased 
pressure especially when the project in question is the 
primary driver of anew strategic direction in the organisation. 
The stability of the project environment also plays a role and 
is the second feature to consider. Project environment 
stability is primarily determined by the organisation’s 
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stability regarding operations (Geraldi et al. 2011). 
Organisations which are unstable and barely functioning 
imply that the project has a minimal chance of being 
executed correctly. The final feature is that of competition 
level with regard to the organisation’s competitors (Senescu 
et al. 2013). Increased competition requires an organisation 
to act swiftly by using projects to push out products and 
services quickly to ensure they remain competitive in their 
relevant industry. 


. Environmental risk is the final element in environmental 


complexity. Environmental risk focusses on man-made and 
natural disaster risks (Floricel et al. 2016; Thomé et al. 2016). 
On the other hand, risks associated with the elements and 
features of environmental complexity should also be 
considered within this element. 


Uncertainty 


Uncertainty is a concept centred on doubt with regard to the 
various elements and features of project complexity (Williams 
1999). The question, however, is how any level of doubt will 
be managed to ensure any negative effect is mitigated during 
a project. The first step is to identify the main elements of 
uncertainty as this will assist doubt management. Various 
elements constitute uncertainty in the project complexity 
context: 


1. 


Uncertainty regarding the traditional project management 
triple constraint should be evaluated (Bosch-Rekveldt et al. 
2011; Geraldi et al. 2011; Thomé et al. 2016). Uncertainty 
about scope is arguably embedded in the scope element of 
technical complexity as much emphasis is placed on project 
requirements. Furthermore, scope creep and poor scope 
management are commonplace during projects where 
strategic pressure coerces the project team to take on a 
project which is unfeasible or unrealistic. The same could be 
argued for the next two features of cost and time uncertainty 
where unrealistic budget and schedule expectations are set 
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for the project which are not met. Alternatively, cost and time 
uncertainty also comes to the fore when there are outside 
influences which were not expected such as Brexit (Dhingra & 
Sampson 2016). 


. The second element of uncertainty concerns project 


activities. Multiple project methods are available for 
managing projects and uncertainty regarding these methods 
inevitably arise (Vidal & Marle 2008). As mentioned 
previously, this is particularly the case when adopting new 
methods. On the other hand, it cannot be assumed that 
all parties understand the method being used when 
introducing new stakeholders and/or project team members 
during a project. Method uncertainty leads to the next 
feature of task uncertainty as project tasks are directly 
influenced by the method being used (Maylor, Vidgen & 
Carver 2008). Task and method uncertainty can be mitigated 
by having adequate support structures and platforms in 
place to which stakeholders and project team members can 
refer. 


. Goal uncertainty is the third element which focuses 


specifically on project goals and objectives (Geraldi et al. 
2011; Maylor et al. 2008). This speaks to goal alignment and 
clarity in technical complexity as uncertainty can be alleviated 
by ensuring these two features are correctly addressed. The 
core idea is that all parties are on the same page throughout 
the project. Furthermore, effective communication and 
collaboration will underpin transparent understanding 
amongst all the participants. 


. Technological uncertainty is very specific and speaks to all 


technological elements and features discussed previously. 
Technological maturity and novelty are the two features 
which underpin this uncertainty element. Whitney and 
Daniels (2013) assert that a key feature of complex IS projects 
is that of new technology which has not yet been fully 
developed and tested, that is immature and novel technology. 
Many projects, however, are deemed failures as the immature 
and novel technology was not implemented correctly and 
thus did not deliver expected business benefits. It is therefore 
essential that novel and immature technology is understood 
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and that there is a balance between new and old technology 
for projects pursuing this route (Tatikonda & Rosenthal 
2000). 

5. Stakeholder uncertainty is the fifth element and refers to 
undisclosed participants and competency. The overarching 
nature of projects such as IS projects requires involvement 
from multiple departments and business units. This could 
arise when certain participants are not identified and their 
presence is not disclosed and disclosed until later in the 
project (Maylor et al. 2008). Omitting participants could lead 
to incorrect or incomplete information being sourced. The 
project manager must therefore continuously check if all the 
required participants have been disclosed during the early 
stages of the project. Competency is also a key feature which 
is underestimated (Maylor et al. 2008). Many projects go 
ahead on the assumption that all stakeholders have the 
knowledge required for executing the project successfully. 
This may not necessarily be the case, however, as key 
individuals could be left out as mentioned previously. 
Furthermore, competency research argues that although IS 
project stakeholders deem themselves competent, the 
mediocre performance of IS projects questions that notion 
(Marnewick, Erasmus & Joseph 2016). If there are questions 
around competency, support structures and materials must 
be in place to mitigate any negative influences. 

6. Information uncertainty is the last element to consider and 
the focus is on incomplete information. Accurate and 
complete information is an undeniable prerequisite for all 
projects as this ensures the project is driven correctly (Vidal, 
Marle & Bocquet 2007). Incomplete information can arise in 
many forms suchas, amongst others, undisclosed participants, 
conflicting norms and standards, unclear goals, cooperation 
and communication as well as trust. 


Dynamics 


Dynamics concerning project complexity refer to the element of 
change management specifically. The change process is the first 
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feature to consider as it should be as robust and adaptable as 
possible (Whyte, Stasis & Lindkvist 2016). Poorly defined change 
processes imply that changes are not instituted correctly or 
managed effectively thus negating any possible improvements 
to a project. The number of changes is also important as projects 
which exhibit multiple changes at once imply the project was 
poorly planned from the outset (Geraldi & Adlbrecht 2007). A 
combination of poorly-defined change processes and a high 
number of changes points to an inevitable outcome for a project. 
Changes are initiated for various reasons which influence the 
scope of changes. For example, some changes might be minor 
while others are widespread and more important (Whyte et al. 
2016). Frequent changes are also a red flag during projects as 
the implication is that there was poor planning and/or previous 
changes were not carried out correctly thus resulting in high 
levels of reworking (Muller, Geraldi & Turner 2012). Along with 
the above-mentioned change management dynamics is that of 
impact. The impact of changes must be clearly understood and 
analysed before implementation as some changes are too risky 
to the outcome of the project and should rather be deferred to 
future projects or project support activities (Geraldi et al. 2011). 
The final feature assesses change over time. Change over time is 
the monitoring and controlling of the above-mentioned features 
to ensure the project continues in the correct direction (Maylor 
et al. 2008). 


E Conclusion 


This chapter revealed that project complexity is ironically 
complex to catalogue and understand. Five complexity 
constructs were identified based on an extensive literature 
review, that is organisational complexity, technical complexity, 
environmental complexity, uncertainty and dynamics. Within 
each construct there are various elements and features. 
A total of 75 features across all constructs were identified 
and discussed. Organisational complexity makes up the bulk 
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of complexity features as this construct has 34 in total. The 
remaining four constructs were fairly evenly divided, which 
implies that organisational complexity is the one construct that 
needs considerable attention. 
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i i 
Insights into 


information system 
project success 


This chapter focuses on project success and how the respondents 
perceived project success within their respective environments. 
The first section of the chapter focuses on the general information 
with regard to the type of respondents and the type of projects 
that organisations implement. This analysis provides us with a 
general understanding of what the IS project landscape looks like. 
The second part of the chapter focuses on project success itself 
and how successful IS projects according to the five levels as per 
Bannerman and Thorogood (2012) are. Specific attention is given 
to the difference between Agile and Waterfall as methodologies 
to implement IS projects. 


How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Insights into information 
system project success’, in The symbiosis between information system project complexity 
and information system project success, pp. 62-80, AOSIS, Cape Town. https://doi. 
org/10.4102/aosis.2017.itpsc45.04 
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FIGURE 4.1: Job description. 


E General information 


The results in Figure 4.1 illustrate that various job titles exist 
within the IS project management domain. The majority of 
the respondents (31.7%) are either project managers or senior 
project managers. The results also highlight that each and every 
one of the respondents is involved in IT and specifically within 
the discipline of project management. 


Figure 4.2 indicates that organisations are involved with 
various types of IS projects covering the full spectrum. The 
majority of the projects (46%) are concerned with either the 
full implementation of IS systems or solutions or the upgrade 
of these systems (17%). This highlights that organisations are 
permanently in turmoil as they are constantly changing or 
upgrading the systems. This places enormous pressure on the IT 
division as well as the users of the various systems. 
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FIGURE 4.2: Type of information system projects. 


The results in Figure 4.2 also highlight that customisations 
and integrations are only about a fifth of the IS projects. It 
must be noted that these are specific IS projects focusing on 
customisation and integration. There might be customisations 
and integrations within the full system implementations as well 
as the upgrades. 


Customisations and integration make use of various 
development methodologies, and this is displayed in Figure 4.3. 
The majority of these types of IS projects make use of either 
the Agile method (41%) or the more traditional Waterfall method 
(31%). A small percentage (8%) are starting to embrace Lean 
and DevOps as ways to implement software solutions. A fifth of 
IS projects incorporate other methodologies to customise and 
integrate software solutions. 


A cross-tabulation between the type of project and the 
development method resulted in Figure 4.4. An interesting point 
of observation is that full systems implementation incorporate 
Agile as a method almost three times more than when an upgrade 
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FIGURE 4.4: Crosstab between type of project and development method. 


is performed. This might have to do with the fact that full systems 
implementation is more pressured for delivery than upgrading 


the system. 


The next section focuses on IS project success, and the 
discussion is based on the five levels of IS project success where 
the first level focuses on the technical processes of an IS project. 


Insights into information system project success 


E Project success 


This section analyses the success of IS projects based on the 
model of Bannerman (2008). Each level is analysed to determine 
the level’s success. This analysis is done for the overall results 
but also for IS projects that used Agile and Waterfall as a method 
within the IS project. 


Process success 


This level focuses on the various technical and managerial 
processes that are important at different times throughout 
the project life cycle (Bannerman 2008). Technical processes 
in this context refer to conducting the actual work to produce 
a deliverable, while managerial processes refer to the oversight of 
the afore-mentioned processes. On average, IS projects are 64% 
successful in the deployment of either a technical or managerial 
process. The detailed breakdown is illustrated in Figure 4.5. The 
results indicate that IS project managers actually spend time 
and effort on the selection, implementation and integration of 
technical and managerial processes. In two-thirds of the instances, 
these processes are aligned with the project’s overall processes. 


However, two-thirds of IS projects cannot be perceived as 
successful as they do not incorporate technical and managerial 
processes into the IT project. 


The results in Figure 4.5 compare the Agile and Waterfall 
methods. Figure 4.6 clearly indicates that IS projects that use 
Agile as a method are successful in incorporating technical and 
managerial processes. In 88.25% of the instances, technical and 
managerial processes are successfully incorporated. In 92% 
of the cases, Agile processes are aligned with the project and 
organisational strategies. 


The results portrayed in Figure 4.6 are in stark contrast to 
the results portrayed in Figure 4.5. The results highlight the 
underlying factor why IS projects continue to fail. The Waterfall 
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processes are not successfully managed and in only 47% of the 
cases are the processes successfully managed. This is a difference 
of 41.25% compared to the Agile processes indicating that Agile 
processes are better managed than the Waterfall processes. 


The results of the study indicate that Agile as a method 
provides an advantage and that the integration, implementation 
and alignment of Agile processes are more successful than the 
integration, implementation and alignment of Waterfall processes. 


The second level of success is based on the project itself, that 
is, was the project delivered within the constraints of time, cost 
and scope? 


Project success 


The constraints of time, cost and scope are the original project 
constraints (Marnewick & Labuschagne 2012). The IT industry 
adopted these constraints from the engineering discipline and IS 
projects should also be delivered within these constraints. Most 
of the research that focuses on IS project success rates use the 
triple constraint as the basis for their analysis. 


Figure 4.7 compares the cost and time constraints against the 
type of IS projects. In four of the instances, IS projects do cost 
more than what was originally budgeted. The only difference is 
with integration projects where the actual cost is 133% cheaper 
than the budgeted cost. When these types of projects are left 
out of the equation, then IS projects are on average 16% more 
expensive than originally budgeted. This implies that 16 cents 
must be added for every one rand that is budgeted. 


The time constraint shows the same kind of tendency as that 
of the cost constraint. The results indicate that IS projects, on 
average, take almost 2 months longer. The biggest discrepancy 
occurs with the implementation of full IS systems. These projects 
take 3 months longer than anticipated. 


The results do not paint such a bleak picture. Although IS 
project managers should strive to deliver the project within 
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FIGURE 4.7: Cost and time comparison. 


the constraints of time and cost, the deviance is not as bad 
as anticipated. IS projects are delivered 3 months later at an 
additional cost of 16 cents to a rand. 


Table 4.1 presents the comparison between Agile and 
Waterfall methods. It is interesting to note that Agile projects are 
30% more expensive than the original budget. Waterfall projects 
are, on the contrary, 11% cheaper than originally budgeted. When 
Agile and Waterfall projects are compared with each other about 
time, then Waterfall projects take 18% longer than estimated and 
Agile projects take 12% longer than estimated. 


The results presented in Table 4.1 convey a mixed message. 
According to the literature, Agile projects should be delivered 
quicker and cheaper than Waterfall projects but this is not the 
case in this instance. This study itself was of a quantitative 
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TABLE 4.1: Cost and time comparison: Agile versus Waterfall. 


Cost and time Agile Waterfall 
Original budget R 5526876.09 R 39398 302.94 
Actual cost R 7882681.12 R 35396 477.77 
Original time 9.60 15.22 

Actual time 10.91 18.63 


nature and no evidence is uncovered why these discrepancies 
exist. It might be useful to conduct interviews with the 
various IS project managers to uncover the truth behind these 
discrepancies. 


The third constraint is the scope of the project. In the context 
of a project, scope is defined as the features and functions that 
characterise the projects deliverable (Project Management 
Institute 2013). The majority of IS projects deliver on the scope 
of the project with 87.5% of these projects delivering on the 
scope between 60% and 100% of the time. Figure 4.8 shows the 
comparison between Agile and Waterfall projects. There is no 
difference between these two methods when it comes to the 
delivery of the scope. Agile projects deliver in 87.5% of the cases 
between 61% and 100% of the scope in comparison with Waterfall 
projects that deliver 89.5% of the scope. 


When Agile and Waterfall methodologies are compared with 
each other with regard to the triple constraint, then there is not 
much difference between the two methods. Project success is 
therefore not dependent on the method that was chosen. 


The third level of success measures the product itself and 
focuses on aspects such as meeting the specifications, meeting 
requirements, meeting client and/or user expectations and the 
final acceptance of the project deliverable by the user. 


Deliverable or product success 


The success of the project deliverable or product was measured 
around seven criteria as illustrated in Figure 4.9. A weighted 


70 


Chapter 4 


705 E Agile Waterfall 
62.3 

60 4 / 
504 
40 4 
30 4 27.2 
20 4 
10 4 74 

p 

25 
1 
oo ma i . . . 
< 20% 21%-40% 41%-60% 61%-80% > 80% 


FIGURE 4.8: Scope comparison (Agile vs Waterfall). 


average score was calculated for each of the seven criteria. 
The results show that the deliverable is only perceived as 68% 
successful when success is determined across all seven criteria. 
This implies that close to a third of the users are not satisfied with 
the project deliverable and that they are actually not using it at all. 


The results indicate that business analysts are fairly competent 
in determining the product’s specifications (71%) as well as the 
users’ requirements (70%). They still cannot determine in 30% 
of the instances either the specifications or the requirements. 
This has a direct result on the remaining five criteria where the 
product is used and accepted in only 68% of the cases. A third 
of the users feel that they are not satisfied with the project 
deliverable and that their expectations were not met. 
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FIGURE 4.9: Deliverable success. 


The results in Figure 4.10 are also not as promising as anticipated. 
On average, Agile projects are only successful 71% of the time in 
delivering a product that meets all the criteria. One of the principles 
of the Agile Manifesto focuses on involving the users or customers 
from the onset. The rationale is that when users or customers are 
involved from the onset, then the chances are better that they will 
accept the project deliverable and actually use it. This builds onto 
the notion that they are involved from the beginning of the project 
and should provide accurate requirements and specifications. 


The concern highlighted by the results is that a quarter of the 
users are not satisfied with the requirements and specifications 
of the project deliverable. This means that the Agile principles 
are not adhered to and that the project team is not trained in the 
various Agile methodologies. 


The average product success for Waterfall projects is 65%, which 
is 6% lower than that of Agile projects as depicted in Figure 4.10. 
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FIGURE 4.10: Deliverable success (Agile vs Waterfall). 


The results highlight that in two-thirds of IS projects that follow 
the Waterfall method, the deliverable does not meet the criteria. 
This creates a serious concern as this implies that business and 
strategic success cannot be achieved. 


The next section focuses on business success and how the 
deliverable of an IS project contributes to the overall success of 
the business. Six criteria contribute to the success of the business. 


Business success 


Organisational leaders invest in a project to gain some benefits. 
Criteria that organisational leaders interrogate are whether the 
project meets the business and project objectives, is the business 
case validated and are the benefits realised as indicated in the 
business case? 


The results in Figure 4.11 indicate that business success is 
not that easily achieved. Business success is achieved in 62% of 
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FIGURE 4.11: Business success. 


IS projects. The business success rate increases to 66% when 
the criteria ‘Unintended benefits’ and ‘Unintended impacts’ are 
removed. It is not always that easy for the project manager to 
plan for these two criteria. The implication is still that a third of all 
IS projects are not perceived as successful at this level. 


In the remainder of the IS projects, IS project managers can 
align the project with the organisational goal (71%) and this results 
in the realisation of benefits (64%). This figure is still extremely 
low given the fact that there is an emphasis on benefits realisation 
in the last couple of years (Aguilera 2016; Bennington & Baccarini 
2004; Marnewick 2016). Adherence to corporate and project 
governance is also disappointingly low (63%) implying that IS 
project managers are not always doing the right thing. 


When the results are analysed based on the method that was 
used, then it seems as if there is no difference between whether 
a project used Agile or Waterfall as a method. The results in 
Figure 4.12 illustrate that there is no difference between these 
two methods. 
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FIGURE 4.12: Business success (Agile vs Waterfall). 


Using Agile as a method improves the chances of 
achieving business success by 1% on average (Agile = 62% vs 
Waterfall = 61%). The results raise more questions. One of the 
questions that needs to be answered is whether IS projects 
actually follow Agile methods or is it merely a lip service? 


The last level of IS project success is determined at a strategic 
level. 


Strategic success 


Investment in an IS project is perceived as a strategic success 
when the project’s deliverable has a positive impact on the market, 
competitors, investors and industry at large. The strategic success 
rate is also not as high as one would hope for. The average success 
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rate is 61% implying that two-fifths of IS projects are failures in 
achieving strategic success for the organisation at large. 


IS projects using an Agile method are far more strategically 
successful than IS projects that are using Waterfall as a method 
(Figure 4.14). 


IS projects using Agile as a method are on average 41% 
more successful than IS projects that use Waterfall as a 
method. The reason is quite obvious. Project deliverables are 
delivered quicker through Agile opening the opportunity for 
quicker impact on the environment at large. The results portrayed 
in Figure 4.14 corroborate the results displayed in Table 4.1. The 
results highlight that Agile projects are delivered 7.7 months 
quicker than projects that use Waterfall as a method. 


E Overall IT project success 


People are not necessarily interested in the detail and want to 
know what the overall success rates are of IS projects. The overall 
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FIGURE 4.13: Strategic success. 
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FIGURE 4.14: Strategic success (Agile vs Waterfall). 
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FIGURE 4.15: Overall success. 


success rate for IS projects are displayed in Figure 4.15. The project 
success level is not included as it is difficult to convert time, cost 
and scope into mere percentages. None of the four levels are 
above 70%, and the average success rate is 63%. 


77 


Insights into information system project success 


The success rate of 63% is a dramatic change from the 2013 
figure of 34% (Marnewick 2013). It is a positive increase of 
29%. This dramatic increase can be attributed to the way that 
project success was measured in this study. Previous studies 
focused on the success of an IS project with regard to time, 
cost and scope. They did not focus on the other levels of 
SUCCESS. 


The longitudinal analysis of IS project success is displayed in 
Figure 4.16. 


The overall success rates are further analysed based on the 
method that was used, that is Agile or Waterfall. The comparison 
is illustrated in Figure 4.17. The two major distinctions between 
Agile and Waterfall are when process and strategic success 
are measured. IS projects making use of Agile principles are 
88% successful when process success is measured and 85% 
successful when strategic success is measured. This is in stark 
contrast with the results of IS projects that made use of the 
Waterfall method. 
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FIGURE 4.16: Longitudinal analysis of information technology project success rate. 
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FIGURE 4.17: Overall information technology project success. 


TABLE 4.2: Overall information technology project success rates. 


Item % 

Overall Agile Waterfall 
Success average 63 I7 54 
Overall rule of 9’s 16 33 8 


The concept of the ‘Rule of 9’s’ appears in the discipline of IT 
service management (ITSM) (Schiesser 2010). Table 4.2 presents 
the average IS project success rates, and it is evident that IS 
projects using the Agile principles are 77% successful versus the 
54% of IS projects that used the traditional Waterfall method. 
The table also illustrates that the success rate of IS projects 
drops from 63% to a mere 16% when the Rule of 9’s is applied. 
This is also the case with Agile and Waterfall where the success 
rates drop to 33% and 8% respectively. 
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E Conclusion 


IS projects are still not out of the woods although there is an 
increase in the success rates. The results highlighted two 
important aspects. IS project success cannot be measured based 
on the triple constraint and a new way of measuring is needed. 
The results underline this principle where a strategic approach 
is needed to measure IS project success. The aim is to deliver a 
product or service that can be used by the customer and that 
provide benefits to the organisation. This new way of thinking 
has seen the increase of IS project success rising to 63%. 


Secondly, it seems that incorporating Agile principles do have 
a positive impact on the success of IS projects. Throughout the 
analysis, projects that incorporate Agile principles do perform 
better. This confirms the results of the 2015 Chaos Chronicles 
where there is a 28% positive difference when Agile principles 
are applied. The South African results indicate a difference of 
23% when Agile principles are applied. 
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IS project complexity does not have extensive exposure within 
literature and thus requires further empirical investigation. 
Chapter 3 revealed that IS project complexity was found to 
have 75 features in total with 34 associated with organisational 
complexity, 13 with technical complexity, 12 with environmental 
complexity, 6 with dynamics and 10 with uncertainty. This 
chapter aims to provide an initial analysis of IS project complexity 
constructs and their respective features. Initial analysis provides 
an overview of which complexity features to be aware of in 
an IS project environment. Furthermore, analysis on IS project 
complexity and IS project development method is also employed 
for further insight. 
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E Information system project 
complexity features 


Each IS project complexity construct was analysed to identify 
the top five features. 


Organisational complexity 


The construct of organisational complexity is directly associated 
with internal complexities in an organisation and consists of the 
most complexity features. Table 5.1 displays the top five features 
within organisational complexity. 


Schedule dependencies is the number one feature to consider 
as it relates to how project tasks and activities are planned and 
allocated. Furthermore, an IS project must be scheduled within 
the context of the organisation so that it has minimal impact 
on day-to-day operations. Skills availability is ranked second 
and implies that the appropriate skills are available to perform 
project tasks. IS projects often require extensive technical 
skills particularly during implementation, as well as soft skills 
for effective management throughout the project (Marnewick, 
Erasmus & Joseph 2016). Capital expenditure is ranked third 
and reiterates the importance of understanding the financial 
support required to execute the project. Experience is ranked 
fourth and relates to experience with involved parties. This 
implies that IS projects perform better if there is some form 
of previous experience with all involved parties as there is a 
better level of understanding and collaboration amongst all. 


TABLE 5.1: Organisational complexity top five complexity features (Overall). 


Ranking Complexity feature 

1 Schedule dependencies 
2 Skill availability 

3 Capital expenditure 

4 Experience 

5 Project duration 
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Finally, project duration is ranked fifth amongst organisational 
complexity features. The duration of a project is a key factor to 
consider when embarking on a new project as this is dictated 
by the strategic importance of the project. As per Table 4.1, it is 
complex to allocate project duration as IS projects are infamous 
for their poor performance regarding the time constraint. 


Further analysis was performed to determine whether there 
was any difference in the organisational complexity feature 
ranking with regard to the IS project development method, that 
is Agile and Waterfall. Table 5.2 shows the top five rankings for 
IS projects using Agile as a method. 


The top two features are the same as the overall ranking of 
organisational complexity features. Project duration moved to 
position three compared to position five. This implies duration 
is more of a complexity feature for Agile projects. It could be 
argued that Agile places more emphasis on delivering quick 
iterations to facilitate a faster project delivery rate. Task 
structure is ranked fourth, which is somewhat surprising given 
that Agile places less emphasis on structure and more on 
deliverables. Conversely, task structure could be more pivotal 
for Agile projects as the project team must continuously re- 
evaluate their progress and realign task structures to meet 
the ever-changing IS project environment. Information system 
dependencies is the fifth ranked feature. The drive to deliver 
iterations to realise project goals requires the support of 
information systems which facilitate an enhanced solution 
development. It is therefore logical that IS dependencies are 
considered as a complexity feature. 


TABLE 5.2: Organisational complexity top five complexity features (Agile). 


Ranking Complexity feature 

1 Schedule dependencies 
Skill availability 

3 Project duration 

4 Task structure 


ao 


Information system dependencies 
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TABLE 5.3: Organisational complexity top five complexity features (Waterfall). 


Ranking Complexity feature 

1 Organisational structure 
2 Schedule dependencies 
5 Resource sharing 

4 Skill availability 

5 Organisational units 


The ranking of organisational complexity features for IS 
projects using Waterfall as a method is depicted in Table 5.3. 
Waterfall complexity features are considerably different to the 
Overall and Agile views. 


Firstly, organisational structure is ranked as the highest 
complexity feature to consider for IS projects which apply the 
Waterfall method. Given that the Waterfall method is heavily 
structured approached and sequential in nature, it could 
be implied that IS projects must be more cognisant of the 
structure when planning and executing the project. Schedule 
dependencies come out second, which aligns closely to the 
Overall and Agile views. It therefore can be concluded that, 
regardless of the method, scheduling is of utmost importance. 
Resource sharing is ranked third and is closely associated with 
the organisational structure as the structure must be understood 
to ensure resources are shared accordingly. Multiple projects 
of various types are executed at any single point in time, thus 
making resource allocation important for Waterfall projects as 
they require significant upfront planning and task delegation. 
Skills availability is ranked fourth and is comparable to the Overall 
and Agile views. Organisational units is ranked fifth for Waterfall 
projects. Similar to the organisational structure’s importance to 
the Waterfall method, understanding what role each unit plays 
during a project is important to ensure the project delivers 
accordingly. IS projects span multiple departments and units 
thus making them increasingly complex to manage. 


The next section analyses the IS project complexity construct 
of technical complexity and its inherent features. 
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Technical complexity 


Technical complexity assesses strategic and tactical 
characteristics which directly influence the project. Table 5.4 
shows the top five technical complexity features for IS projects. 


Risks associated with the technical aspects of an IS project 
are ranked first. Technical project characteristics are usually 
considered during the initiation and planning phases but are 
influenced during a project as well. The implication is that 
technical characteristics must be part of the continuous risk 
management as these add to the complexity of managing a 
project. IS projects thrive on technology and employ new 
technology wherever possible. Newness of technology is ranked 
second and confirms that the use of new technology poses risks 
as increased complexity arises. Chapter 4 notes that 71% and 70% 
of specifications and requirements are met respectively (refer to 
Figure 4.9). Scale of scope is ranked third and implies that project 
scope is an important feature to consider to ensure a project 
does not become overly complex. Not only must the scope be 
well defined but also realistic to ensure the project can actually 
be delivered. The number of tasks is ranked fourth. Project tasks 
form the basis of any project and the number of them should not 
be overwhelming and make the project increasingly difficult to 
execute. The number of tasks is associated with the task structure 
in organisational complexity as these work in tandem. It could be 
argued that the number of tasks could be attributed to IS projects 
deviating from the original time and cost (Table 4.1). Finally, the 
variety of tasks is ranked fifth for technical complexity features. 
Variety of tasks speaks to the skills availability of organisational 


TABLE 5.4: Technical complexity top five complexity features (Overall). 


Ranking Complexity feature 
1 Technical risks 


Newness of technology 
3 Scale of scope 


A 


Number of tasks 


ao 


Variety of tasks 
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complexity as many tasks require different skill sets at different 
proficiency levels. The project can only be delivered if the 
appropriate skills are available or sought after. 


The top five features of technical complexity when Agile is 
adopted are presented in Table 5.5. 


Technical risks and newness of technology are once again 
ranked first and second for Agile projects respectively. Variety of 
tasks is ranked third and implies that Agile projects include more 
task variety during a project. The adaptive and flexible nature of 
Agile suggests that there will be more task variety as solution 
development will go through multiple iterations based on user 
feedback particularly. Diversity of inputs and outputs is ranked 
fourth and relates to the argument around the variety of tasks 
as well. Furthermore, inputs and outputs are not predefined for 
Agile projects implying that there is more inherent diversity which 
contributes to complexity. Scale of scope is ranked fifth and 
implies that although Agile projects also rely on well-documented 
scope, they are more open to scope changes and alterations to 
ensure the project delivers as intended. Furthermore, Chapter 4 
revealed that Agile projects meet specifications and requirements 
more successfully than Waterfall projects. 


The ranking of technical complexity features for IS projects 
using Waterfall as a method in Table 5.6 is very similar to the 
Overall view of complexity features albeit in different order. 


Technical risks is ranked first for the Overall, Agile and 
Waterfall views of IS projects which confirms its importance 
from a complexity perspective. Scale of scope is ranked second 
highest in Waterfall projects. The Waterfall method is much more 


TABLE 5.5: Technical complexity top five complexity features (Agile). 


Ranking Complexity feature 


1 Technical risks 

Newness of technology 
Variety of tasks 
Diversity inputs/outputs 


Oop WRN 


Scale of scope 
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TABLE 5.6: Technical complexity top five complexity features (Waterfall). 
Ranking Complexity feature 
1 Technical risks 


Scale of scope 
5 Number of tasks 


A 


Newness of technology 


ao 


Variety of tasks 


procedural and thus requires significant time spent on planning 
and designing an IS project solution. The scope is expected to 
be more detailed and complete, which makes it a significant 
technical complexity feature. Alternatively, Figure 4.10 contends 
that Waterfall projects deliver less on requirements and 
specifications, which contrasts with its approach of well-defined 
scope development. The number of tasks is ranked third and is 
more important for Waterfall projects as the number of tasks is 
defined early and is not as flexible as Agile projects. Waterfall 
projects rank newness of technology fourth implying that, 
although it is an important feature, it does not have the same 
significance as in the Overall and Agile views. It could be that new 
technologies are intensively evaluated up front before adoption 
to decrease possible project complexities. Finally, the variety of 
tasks is ranked fifth and implies that Waterfall projects consider 
task variety somewhat less than Agile projects. This does not, 
however, negate the importance of understanding the various 
tasks required to execute an IS project. 


An analysis of environmental complexity features is performed 
in the following section. 


Environmental complexity 


Environmental complexity assesses the internal and external 
organisational environment in which the project operates. The top 
five environmental complexity features are shown in Table 5.7. 


Stakeholder perspectives can vary during IS projects thus making 
it difficult to satisfy all stakeholders. Stakeholder perspectives is 
ranked number one for IS projects in general, which implies it is 
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TABLE 5.7: Environmental complexity top five complexity features (Overall). 


Ranking Complexity feature 

1 Stakeholder perspectives 

2 Internal strategic pressure 

5 Number of stakeholders 

4 Stability of project environment 
5 Political influence 


increasingly complex to manage stakeholder expectations and 
to realise stakeholder satisfaction across the board. Constant 
communication and interaction with all stakeholders are a means 
to limit the complexity associated with varying perspectives. 
Internal strategic pressure results from the pressure of senior 
management expectations regarding the project. This feature 
is ranked second and implies that IS projects experience higher 
levels of complexity because of internal strategic pressure. As 
mentioned, meeting all expectations is difficult and should be done 
as best possible. The number of stakeholders is ranked third and 
speaks to the complexity managing multiple internal and external 
stakeholders involved in a project. Project communication is 
more difficult than previously believed and is a skill set required 
to ensure all stakeholders have an equal understanding of the 
project at hand (Marnewick et al. 2016). IS projects which have 
a large number of stakeholders increase complexity given the 
communication challenges. Projects should operate within a 
stable environment and with minimal negative impacts occurring. 
The stability of project environment is ranked fourth implying 
that it is a challenge maintaining a stable environment for the 
project to thrive and exist freely. The organisational environment 
has a direct impact on the project environment as any instability 
would influence how a project is executed. Political influence is 
ranked fifth and relates to internal politics particularly. Internal 
politics primarily arise from stakeholders with senior authority, 
such as executives. There could be cases where executives insist 
on changing business requirements and scope without fully 
understanding the intricacies and influences on other complexity 
constructs and features. 
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The top ranking environmental complexity features when 
using Agile as a method, is shown in Table 5.8. 


Stakeholder perspectives remain top, which further iterates 
the importance of stakeholder management. The number 
of stakeholders is ranked second, one position higher than 
the Overall view. The implication therefore is that Agile 
projects are more complex with regard to the management of 
stakeholders given the top two rankings. Furthermore, this is 
in line with the Agile Manifesto, which stresses a people rather 
than a process focus (Beck et al. 2001). Internal strategic 
pressure is ranked one position lower but still indicates that 
the organisation at large has a direct influence on IS project 
management. Although Agile IS projects are more flexible 
and adaptable, there must still be the semblance of a stable 
operating environment. Stability of the project environment 
is ranked the same at position four and further solidifies its 
importance for Agile projects. Interestingly, Agile projects 
are more complex with regard to understanding the level of 
competition in the industry as it is ranked fifth. Agile projects 
aim to deliver projects rapidly so that business value can be 
realised as soon as possible. Complexity arises when competing 
within the organisation’s industry as this requires even more 
focus delivering solutions rapidly to gain or expand market 
share. This notion is further support by findings in Chapter 4, 
which confirm that Agile has greater market and industry 
impact (refer to Figure 4.14). 


The environmental complexity features for Waterfall projects 
are shown in Table 5.9. 


TABLE 5.8: Environmental complexity top five complexity features (Agile). 
Ranking Complexity feature 
1 Stakeholder perspectives 


Number of stakeholders 
3 Internal strategic pressure 


A 


Stability project of environment 


ao 


Level of competition 
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TABLE 5.9: Environmental complexity top five complexity features (Waterfall). 


Ranking Complexity feature 

1 Stakeholder perspectives 
2 Internal strategic pressure 
5 Number of stakeholders 

4 Political influence 

5 Internal support 


Stakeholder perspectives is still ranked number one and 
confirms that it is a complexity feature which needs the utmost 
attention. Internal strategic pressure maintains its top three 
ranking as itis ranked second for Waterfall projects. The number 
of stakeholders also holds its top three position as it is ranked 
third. The top three for the Overall, Agile and Waterfall views 
is particularly focused on stakeholder management, which is 
more prevalent in modern project success literature (Joseph & 
Marnewick 2014; Todorović et al. 2015; Williams 2016). Political 
influence is included for Waterfall projects and is ranked fourth. 
Internal politics seem to affect the Waterfall project complexity 
more and must therefore be mitigated and managed as 
effectively as possible. Finally, internal support is introduced 
for the Waterfall projects as it is ranked fifth. Waterfall 
projects arguably suffer from a lack of management support 
from stakeholders such as project sponsors. This introduces 
increased complexity as management support is required to 
ensure the project aligns to the greater organisational goals. 


Project complexity includes the construct of dynamics, which 
is analysed in the next section. 


Dynamics 


The construct of dynamics focuses specifically on change 
management practices and characteristics within an IS project. 
Rather than ranking the top five, Table 5.10 ranks all the features 
as there are only six features within the dynamics construct. 


The number of changes is ranked first overall and implies 
that the actual quantity of changes is complex to manage. 
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TABLE 5.10: Dynamics top six complexity features (Overall). 
Ranking Complexity feature 


Number of changes 
Impact of changes 
Change process 
Scope of changes 
Change over time 


0 R c WN 7 


Frequency of changes 


IS projects inherently have multiple changes throughout the 
project, but the number of these changes should not be high 
as multiple changes could imply that the project was not 
completely understood and thus poorly developed. The impact 
of changes is ranked second and should not be ignored as small 
changes can have a large impact either positively or negatively. 
Complexity increases particularly when negative changes occur 
which derail the project, especially with regard to time and 
cost. Complexity around the actual change process is ranked 
third. Given that change is inevitable, an appropriate and well- 
designed change process should exist to ensure changes are 
managed effectively and are predominately positive. Scope of 
changes is ranked fourth and focuses on the detail around the 
expected changes. Similar to number and impact of changes, 
the scope of changes should not be overwhelming as this would 
suggest poor design. Although there are multiple changes 
throughout a project, changes should have a fluctuation 
pattern rather than maintain a continuous high level of changes. 
Change over time and frequency of changes is ranked fifth and 
sixth respectively and are comparable to scope of changes. 
It becomes increasingly complex to manage a project with 
frequent changes which change significantly over time. 


The top six dynamics features when adopting Agile as a 
method are presented in Table 5.11. 


Managing the number of changes is still complex for Agile 
projects as it is again ranked first. Change process has more 
emphasis in Agile projects, which is logical given that Agile uses 
continuous feedback to update and enhance the solution. The 
change process must therefore be expedited to maintain iterative 
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releases. Scope of changes is ranked one position higher at third 
and implies that Agile projects face complexities around change 
scope when delivering the various iterations. The impact of 
changes is ranked lower at fourth, which arguably is consistent 
with the fact that Agile minimises change impact through iterative 
releases. Change frequency is important regardless and is ranked 
one position higher for Agile at fifth. Interestingly, change over 
time is considered the least complex for Agile projects, which 
also corresponds with the notion that iterative releases facilitate 
change management more effectively. 


Dynamic complexity features for IS projects using the 
Waterfall method, is ranked in Table 5.12. 


The impact of changes is ranked top for Waterfall projects 
which is significantly higher than the Agile project rankings. This 
implies Waterfall projects face greater challenges when managing 
change impact. The number of changes maintains its top two 
ranking for the Overall, Agile and Waterfall views. This confirms 
that it is important to not have too many changes at any single 
point in time as this could detract from IS project execution and 
negatively affect realising the project goals. Complexity around 


TABLE 5.11: Dynamics top six complexity features (Agile). 


Ranking Complexity feature 


Number of changes 
Change process 
Scope of changes 
Impact of changes 
Frequency of changes 


o E > WN A 


Change over time 


TABLE 5.12: Dynamics top six complexity features (Waterfall). 


Ranking Complexity feature 


Impact of changes 
Number of changes 
Change process 
Change over time 
Scope of changes 


0 W S WN A 


Frequency of changes 
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the change process is also apparent for Waterfall projects and thus 
signifies the importance of having a well-designed change process 
regardless of the project methodology employed. Waterfall 
projects consider it more complex to manage change over time 
as it is ranked fourth. This could be that Waterfall projects mainly 
address changes towards the end of the project rather than 
continuously and throughout the project. Interestingly, scope of 
changes is ranked fifth and is considered not as complex compared 
to the previously discussed features. Waterfall projects arguably 
do not worry as much about the scope of changes because they 
expect to implement multiple changes during the final project 
stages. Frequency of changes maintains its low ranking at sixth 
and serves to confirm that complexity around this feature is low as 
the previous features aim to mitigate frequent changes. 


The following section analyses the final project complexity 
construct of uncertainty. 


Uncertainty 


Uncertainty assesses the level of doubt and vagueness inherent 
in IS projects, and the Overall ranking for IS projects is showed 
in Table 5.13. 


Uncertainty regarding time is the most highly ranked 
complexity feature overall. Time is one of the triple constraints 
which are often argued as a key success criterion within project 
management. Complexity around managing time uncertainty 
therefore makes logical sense. Incomplete information is ranked 
second and implies that IS projects experience significant 


TABLE 5.13: Uncertainty top five complexity features (Overall). 


Ranking Complexity feature 
1 Time 


Incomplete information 
5 Cost 
Competency 


o SS 


Scope 
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complexity regarding poor information dissemination. Incomplete 
information such as poor requirements and specifications has a 
detrimental effect on project delivery and subsequent success. 
Cost is another component of the triple constraints which is 
argued as important. It is ranked third from an uncertainty 
perspective. Doubt around cost escalates quickly as it has a 
knock-on effect on the project as a whole and can easily overshoot 
planned estimates. Project competency is a strongly debated 
topic in the IS project realm and brings to question whether IS 
project managers have the appropriate skills and knowledge to 
execute projects (Joseph & Marnewick; Marnewick et al. 2016). 
Competency is ranked fourth and implies that it is increasingly 
complex to ensure adequate competency exists for the project to 
be executed correctly. Scope is ranked fifth within the uncertainty 
construct of the IS project complexity. Scope uncertainty exists 
predominantly when poor understanding and design exists. 
Quality requirements is somewhat of a misnomer as literature 
argues that practitioners do not take a holistic view during the 
design of a solution and subsequently produce mediocre inputs 
for development (Fernandez et al. 2015; Tamai & Kamata 2009). 


Agile projects’ top uncertainty features are shown in Table 5.14. 
The top three features are identical to the Overall view signifying 
their importance. Scope is ranked one position higher at fourth, 
implying Agile environments are slightly more complex regarding 
the management of scope uncertainties. 

Agile’s iterative and flexible environment suggests that scope 
must be managed more carefully, otherwise the project could 


become disjointed and not deliver as expected. Interestingly, 
Agile introduces the feature of technological maturity as it is 


TABLE 5.14: Uncertainty top five complexity features (Agile). 


Ranking Complexity feature 

1 Time 

2 Incomplete information 
3 Cost 

4 Scope 

5 Technological maturity 
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TABLE 5.15: Uncertainty top five complexity features (Waterfall). 
Ranking Complexity feature 
1 Time 


Incomplete information 
3 Scope 


A 


Competency 
Cost 


ao 


ranked fifth. Agile arguably prefers using mature technology as 
this would facilitate the fast-tracking of solutions to the market 
as the team would have experience with adopted technology. 
Conversely, it is complex to manage Agile projects which use 
innovative and untested technology as experience will be lacking. 


Table 5.15 shows the top five rankings for uncertainty features 
for Waterfall projects. Time and incomplete information maintain 
their top two positions once again. 


It is therefore clear that that these two features add to IS 
project complexity regardless of the methodology employed. 
Furthermore, time uncertainty is arguably apparent in Table 4.1 
where actual time deviates significantly from originally planned 
time. Scope uncertainty is ranked highest for Waterfall projects, 
which implies there is considerable doubt regarding upfront 
scoping activities and that these projects battle with scope issues 
throughout. Similar to the Overall view, competency is ranked 
fourth when adopting the Waterfall method. Cost uncertainty 
is ranked fifth implying that Waterfall projects do not consider 
cost as a complex feature. This aligns to the findings in Chapter 
4, which argue that Waterfall projects’ actual cost is less than the 
original budget (Refer to Table 4.1). 


The following section provides a holistic view of complexity 
features by analysing them across all constructs. 


E Overall complexity view 


The previous sections focus on the rankings of features within 
a single complexity construct. The aim of the section is to 
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elaborate on the previous findings by investigating the top five 
and bottom five rankings across all five constructs. Table 5.16 
provides an overview of the top and bottom five ranked features 
of all constructs regardless of the method of orientation. 


Technical risks ranked top overall implying that IS projects 
complexity is primarily driven by project technicalities, that is 
project goals, scope, tasks and technology experience. Schedule 
dependencies is ranked second, which is logical given that project 
management is a culmination of tasks required to deliver a successful 
project. IS projects often face the dilemma of selecting technology 
to adopt and implement. This is confirmed by the ranking of 
newness of technology at third. Scope has been argued in previous 
sections as a contentious issue which plagues IS projects. IS 
projects face significant complexities regarding the scale of scope 
as it is ranked fourth. Finishing off the top five is skill availability and 
speaks directly to one of the most important resources required 
for delivering a project. The project team particularly requires 
extensive skills to not only manage an IS project but also implement 
it. Interestingly, the top five features are predominantly technical 
complexity features implying that IS projects should focus more 
on technical aspects than anything else. It could be argued that 
dealing with technical complexities could have a positive effect on 
other complexity constructs and features. 


The bottom five begins with undisclosed participants. IS 
project environments do not consider this a complexity feature 
which requires much attention. It has previously been argued 
that all stakeholders should be accounted for to ensure the 


TABLE 5.16: Top five and bottom five complexity features across all construct. 


Ranking Top 5 Bottom 5 

1 TC technical risks U undisclosed participants 
2 OC schedule dependencies OC HSSE 

3 TC newness of technology OC different languages 

4 TC scale of scope EC remoteness 

5 OC skill availability EC weather conditions 


HSSE, health, safety, security and environment; TC, technical complexity; OC, organisational complexity; 
EC, environmental complexity. 
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project delivers accordingly. Yet, this feature is ranked as one of 
the lowest. This could possibly be a fundamental indication why 
IS projects perform poorly because they merely move forward 
without comprehensive input from all involved. The second 
lowest ranked feature is health, safety, security and environment 
awareness implying that |S project environments omit complexities 
associated with health and safety. Different languages used in a 
project is considered the third lowest complexity feature, which 
is surprising in the South African context given that the diverse 
nature of the country includes the use of multiple languages. 
Nevertheless, complexity around language is considered mediocre 
and does not contribute sufficiently to IS project complexity. The 
fourth lowest ranking is remoteness regarding the location or site 
of the project deployment. The implication is that team members 
and stakeholders do not face any difficulties accessing the project 
site and logistics are not as complex. Weather conditions was 
ranked the lowest of all the complexity features and implies that 
IS projects continue regardless of the weather. 


Similar to the individual assessment of complexity features, 
this section will analyse features when different methodologies 
are employed. Table 5.17 indicates the top and bottom five 
feature rankings in an Agile project. 


Schedule dependencies is the most highly ranked complexity 
feature, which confirms that IS projects battle to manage their 
schedule as the environment continuously changes during the 
project. Agile projects view technical risks as the second most 
important and is comparable to the overall view of complexity 
features. Newness of technology retains its position at third 


TABLE 5.17: Top five and bottom five complexity features across all constructs (Agile). 


Ranking Top 5 Bottom 5 

1 OC schedule dependencies U undisclosed participants 
2 TC technical risks OC different nationalities 
5 TC newness of technology EC remoteness 

4 OC skill availability OC different languages 

5 D number of changes EC weather conditions 


OC, organisational complexity; TC, technical complexity; EC, environmental complexity; D, dynamics. 
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and further iterates the importance of technology adoption and 
implementation. Fourth is skill availability, which arguably confirms 
that skills develooment and exploitation is a prerequisite in the IS 
project realm. Agile projects are known for their iterations based on 
feedback which lead to evolving changes. The number of changes 
is ranked fifth and confirms that Agile projects face complexity 
challenges regarding the management of multiple changes. Even 
though Agile proclaims adaptation, multiple changes can become 
cumbersome and adversely impact an IS project. 


Undisclosed participants is once again ranked first further 
implying its lack of complexity. Agile projects rank different 
nationalities as the second lowest suggesting that organisations 
have embraced the inclusion of multiple nationalities working 
together given the modern landscape in which they operate. 
Remoteness is ranked third while different languages is ranked 
fourth. Weather conditions continues not to be a complex matter 
as it is once again ranked last. 


Table 5.18 indicates the top and bottom five feature rankings 
in Waterfall projects. 


Waterfall projects rank technical risks as top, which confirm 
their complex nature to manage. Varying stakeholder perspectives 
are introduced as a high-ranking complexity feature at position 
two. It seems increasingly difficult to maintain and manage 
various perspectives for Waterfall projects, which could be a key 
attributing feature influencing IS project performance. Scale of 
scope appears again as it is ranked third. The rigid nature of the 
Waterfall method could be the reason why scope continues to be 
a complex issue as the idea is that the scope is defined upfront 


TABLE 5.18: Top five and bottom five complexity features across all constructs (Waterfall). 


Ranking Top 5 Bottom 5 

1 TC technical risks U undisclosed participants 
2 EC stakeholder perspectives OC HSSE 

3 TC scale of scope OC different languages 

4 TC number of tasks EC remoteness 

5 TC newness of technology EC weather conditions 


OC, organisational complexity; TC, technical complexity; EC, environmental complexity; D, dynamics. 
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and should not change. The fourth-ranking feature combines 
some tasks that imply that Waterfall projects are not as adept at 
task management compared to Agile projects. Although ranked 
lower than the Overall and Agile views, newness of technology 
maintains its position in the top five complexity features. IS 
projects emphasise technology and it is, therefore, logical that 
new technology complexities inherently exist for IS projects. 
Technical complexities make up four of the five top ranked 
features, which is similar to the argument made for the Overall IS 
project complexity view. 


The bottom five features are comparable to the Overall and 
Agile views, which confirms that they are far simpler to manage 
than other complexity features. 


E Conclusion 


The aim of this chapter was to indicate which features in an IS 
project are considered most complex so that practitioners can 
make adequate provision for managing them. The rankings 
for the overall and individual views of constructs show that no 
environment is the same and that each view complexity in a 
different light. Many features align with the environment they 
operate in, that is, Agile and Waterfall. The analysis of the top 
five complexity features does not show one construct as more 
complex than another construct. What is evident is that features 
from technical complexity construct occur nine times within the 
top five features with organisational complexity in the second 
place. IS project managers should analyse the various complexity 
constructs and address the features one by one in order to 
reduce the overall complexity of the project. 


The subsequent question is: How does one manage these 
complexity features to ensure they do not adversely affect 
project delivery? Ironically, understanding IS project complexity 
is complex in itself, which is why further analysis is required to 
illuminate its inherent intricacies. 
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IS project success 
and complexity 


All the constructs related to IS project success and IS project 
complexity are represented in Appendix A. The various respective 
elements and features are also included for ease of reference. 
Moreover, observed variable names were defined as this would 
act as a cross-referencing tool for the data analysis below. 


E Conceptualising the symbiosis 
between information system project 
success and complexity 


Project success and complexity are often viewed in isolation with 
no real link argued between the two. However, in the real world 
there is an indefinite association between the two concepts. 
Chapters 2 and 3 discussed the concepts separately in detail as 
these formed the foundation of articulating the symbiosis which 


How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Symbiosis between IS project 
success and complexity’, in The symbiosis between information system project complexity 
and information system project success, pp. 100-136, AOSIS, Cape Town. https://doi. 
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inherently exists. The models represented in this chapter are based 
on the logical mappings depicted and argued in this section. 


The concept of project success has many definitions which 
have varying perspectives and thus create an element of 
incongruity in the project management landscape. Chapter 2 
presented the five level model of project success to encapsulate 
the concept from an IS perspective. The concept of project 
complexity has also resulted in multiple views being developed, 
which has culminated in a multidimensional perspective of the 
concept. Chapter 3 subsequently presented a five dimensional 
view for IS project complexity based on an extensive literature 
review. The question posed here is how these views relate 
theoretically and logically prior to further data exploration. 
A conceptual theoretical model for the symbiosis between 
IS project success and IS project complexity is presented in 
Figure 6.1. 


Organisational complexity spans the entire five level view of 
project success as IS projects are executed within the organisational 
context to facilitate the realisation of the business and strategic 
goals. An organisation’s structural orientation affects everything 


Organisational complexity + Environmental 
complexity 


Product Organisational benefit 


Project 


Process i Business Strategic 
management Deliverable success g 
success success SUCCESS 
success 


Technical complexity + 
Dynamics + Uncertainty 


FIGURE 6.1: Symbiosis of information system project success and information system 
project complexity. 
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from the project process to long-term strategic success as the 
organisational structure and business units directly influence how a 
project is executed. The element of size pertains to attributes of an 
IS project such as project duration, variety of methods and capital 
expenditure, for example. Size thus plays a role that influences 
process and project management success as each attribute pertains 
to the groundwork that is performed for a project. Resources within 
organisational complexity elaborate areas which pertain to business 
and strategic success distinctly, such as project drive. Areas such as 
resource and skills availability as well as experience with involved 
parties align to project management and deliverable success as 
both embrace effective project management execution to deliver 
valuable product output. The project team and trust elements have 
implications regarding process and project management success as 
social dynamics propel and support the execution of an IS project. 
Interdependencies and risk span the entire five level landscape as 
each feature influences one or multiple success levels. 


Environment complexity comparably covers all five levels of 
project success as well. Process and project management success 
are encapsulated by the elements of stakeholders and location. 
The location element speaks to attributes and intricacies regarding 
the project site. Process and project management success is 
dependent on these environmental attributes as they influence the 
activities required to execute a project. Stakeholders is an element 
which emphasises stakeholder management, which is key to 
realising process and project management success. Furthermore, 
stakeholders aligns to deliverable success as the management of 
stakeholders such as the end user aims to ensure the project delivers 
its output goal. Business and strategic success is driven by the need 
to compete within a competitive global landscape. These two levels 
of organisational benefit are affected by complexities surrounding 
environmental stability, strategic pressure and competition 
level, which are represented in the market conditions element of 
environmental complexity. Environmental risks span all success 
levels as risks are inherent regardless the status of each level. 


Technical complexity is inherently focused project management 
as each of the features revolve around project management activities 


102 


Chapter 6 


specifically. Inferences exist, therefore, that technical complexity 
engages with the levels of process and project management 
success. Differentiation relates to inout and output diversity, which is 
intrinsic of project management as a whole and the processes which 
support it. Goals is specific to project goals and their alignment to 
greater strategic initiatives. This is dealt with on the ‘ground’ level 
where project activities are executed as each activity is aligned to 
the greater project goal. The realisation of the project goal is not 
the main concern during the project management phase as the 
focus is on delivering the project with assessment done later on. 
The elements of scope and task once again focus on actual activities 
and how they are performed, which is project management itself. 
Experience from a technical complexity view regards the challenges 
dealing with technology in an IS project. This experience, therefore, 
relates to project management success as the focus is on how 
technology is used in the project to realise the project goal. Similar 
to organisational and environmental risks, technical risks appeal to 
process and project management risks at the ‘ground’ level. 


Uncertainty incorporates elements and features around doubt 
and vagueness, which is directly associated with process and 
project management success. The triple constraints of time, cost 
and scope are a project management assessment tool and are 
specific to an individual project. Method and task uncertainty has 
a process and project management orientation that is particular 
to hands-on activities. The elements of goals, technology and 
stakeholders uncertainty are project management specific as 
they all deal with characteristics of the project itself and not 
success areas after the project. This, however, does not negate 
any possible propagating effect to the following project success 
levels. Information uncertainty and vagueness occur regardless 
of the various project management processes in place, which is 
why it relates to process and project management success. 


Project experience changes throughout and requires robust 
change management practices to maintain project momentum. 
Change management is covered in the dynamics construct 
and is particular to the project itself, which implies that process 
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and project management success are once again influenced. 
Change management is particularly important for IS projects as 
methodologies have different approaches which influence its 
practice. For example, Agile projects profess adaption and iteration 
which require robust change management practices and processes. 


The discussion above argues the logical mapping of IS project 
success and complexity to convey symbiosis of the two concepts. 
The subsequent model development and analysis is based on 
these mappings to illuminate the symbiosis. 


E Development and analysis of IS 
project success models 


The third section of the questionnaire requested the respondents 
to provide their impressions regarding what affects project 
success on various levels. These five levels were identified from 
the research performed by Bannerman (2008): 


e Level 1: Process success. The need to consider technical and 
managerial aspects in completing the project task. 

e Level 2: Project management success. The immediate 
performance of the project with regard to budget, scope 
and schedule. 

e Level 3: Deliverable success. The measures of information 
quality, system quality, service quality, intention to use, actual 
use, user satisfaction, and net benefits. 

e Level 4: Business success. The ability of the project to 
successfully meet the needs or solve a business problem the 
customer is experiencing. 

e Level 5: Strategic success. This criterion represents the highest 
level of benefit achieved by a project, despite the possibility of 
failures against lower level criteria, as recognised by external 
stakeholders such as investors, industry peers, competitors, or 
the general public, dependent upon the nature of the project. 


One level is omitted in the discussion that follows, that is Level 2 
that focuses on project management success. The questionnaire 
requested specific data from the respondents which is not 
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conducive for modelling. The other four levels were measured 
using a 5-point Likert scale. Suffice to say that various other studies 
have been able to determine the various critical success factors and 
causes of failure (Marnewick, Erasmus & Joseph 2016). 


What follows is a discussion on the Overall factors and model 
as well as an investigation into the differences between Agile 
and Waterfall projects. 


Overall results 


The Overall results closely reflected the research done by 
Bannerman (2008) in that three of the levels were clearly 
identified. The following factor loading is the result of factor 
analysis through statistical software (Figure 6.1). 


All the relevant variables associated with the different levels 
associated with four factors. Factor 1 included all the variables of 
deliverable success. These were: 


e requirements met 

e specifications met 

e client and/or user specifications met 
e client and/or user acceptance 

* product and/or system used 

e client and/or user satisfied 

e client and/or user benefits realised. 


These clearly relate to Level 3 of the Bannerman (2008) model 
and therefore Factor 1 can confidently be labelled as Deliverable 
success. However, there are other variables, not thought of 
as part of deliverable success in the original model, that are 
associated with this factor. These are: 


e goals and/or objectives 
e business plan 
e benefits realisation. 


These variables are identified as forming part of Business 
success or Level 4. On examination it would seem these three 
variables bear some relation to product success in the mind of 
the respondents. 
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TABLE 6.1: Overall factor loadings with Pattern Matrix. 


Observed Factor 

variable? 1 2 3 4 
DS_06 0.851 

DS_04 0.842 

DS_03 0.800 

DS_O2 0.748 

DS_07 0.728 

DS_O5 0.648 

DSZO] 0.626 

BS_04 0.574 

BS 01 0.561 

BS_02 0.370 

$5.03 0.756 

SS_04 0.734 

Ss 01 0722 

SS_02 0.690 

659 05 0.603 

SS_06 0.587 

PS_O1 C772 

PS_03 0.735 

PS_O2 0.698 

PS_O4 0.654 

BS_05 1.018 
BS_06 0.587 


Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and 
Rotation Method: Promax with Kaiser Normalisation. 
a, Variable names and associations are presented in Appendix A. 


Factor 2 contained all the variables associated with strategic 
success on Level 5 of Bannerman’s model. These are: 


e market impact 

e industry impact 

e competitive impact 
e investor impact 

e regulator impact 

e other impacts. 


Therefore, Factor 2 can be labelled as Strategic success and 
correlates strongly with what literature determines. 
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Factor 3 includes all the variables labelled as part of process 
success. These are: 


e Processes appropriately chosen for the intended purpose. 
e Processes aligned with project objective. 

e Processes appropriately integrated with one another. 

e Processes effectively implemented. 


Therefore, Factor 3 correlates strongly with what Bannerman 
(2008) identified as Level 1 and can be labelled as Process 
SUCCESS. 


Two remaining variables are grouped into Factor 4. These 
variables are: 


e Extent to which the project achieved unintended benefits. 
e Extent to which the project achieved unintended consequences. 


These variables are associated with business success in 
literature. However, on their own, it may not be apparent that 
they belong there. Given the ‘unknown’ description of both of 
these variables, perhaps the data can be interpreted differently. 
This factor is labelled as the Unknowns of project success as it 
refers to impacts and consequences of conducting project work. 
These impacts are difficult to plan for or to anticipate without 
extensive due diligence activities. 


These factors are all confirmed with Cronbach Alpha values 
of 0.9 and above (Field 2013). Therefore, the researchers are 
confident about the validity of the four identified factors. These 
could be depicted as per Figure 6.2. 


The next step is to attempt to determine a model. The purpose of 
such a model is to ascertain whether there are links between these 
different factors and whether or not there are correlations between 
one another. This is done through the process of Structural 
Equation Modelling (SEM). The following model (Figure 6.3) 
emerged after numerous iterations. 


This model clearly indicates that these different levels have 
medium to strong relationships to one another, the strongest 
being between Process success and Deliverable success. This is an 
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FIGURE 6.2: Project success level factors. 


expected result as it would be difficult to imagine that a deliverable 
can be produced without completing proper processes. Recall 
that Bannerman (2008) indicated that these levels need not 
necessarily be related to achieve success on higher levels. While 
these results do not directly contradict Bannerman (2008), they 
indicate that there is a relationship nonetheless. The outcome on 
lower levels would seem to have an impact on the outcome on 
higher levels. 
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FIGURE 6.3: Unconfirmed model for project success levels. 
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This model can be confirmed as valid. 


The following model 


fit data was obtained from the SEM process as depicted in Table 6.2. 


Therefore, for the purposes of this data set, we can confidently 
conclude that IS project managers take cognisance of the 


following levels of project success: 
e Level 1: Process success. 


e Level 2: Project management success as determined by previous 


studies. 
e Level 3: Deliverable success. 
e Level 4: Strategic success. 


TABLE 6.2: Model fit data for Overall model for project success. 


Model fit Description Cut-off Results 
measures levels 
employed 


Reference 


Absolute fit CMIN/DF SS: 2.82 
measures 


RMR < 0.05 0.04 


GAEI 20.9 0.92 


Relative fit NFI 20.9 0.93 
measures 


TLI 209 0.94 


CFI > 0.95 0.95 


Fit measures RMSEA < 0.08 0.06 
based on the 

non-central 

chi-square 

distributions 


Gaskin (2013e); Marsh and 
Hocevar (1985); McKinney 

et al. (2002); Roh, Ahn and 
Han (2005) ; Ullman (1996); 
Yatim (2008) 

Roh et al. (2005); 
Tabachnick and Fidell (1996); 
Doloi, lyer and Sawhney 
(2011); Kim et al. (2009); Roh 
et al. (2005);Tabachnick and 
Fidell (1996) 

Doloi et al. (2011); Stahl 
(2008); Tabachnick and 
Fidell (1996); Yatim (2008); 
Doloi et al. (2011); Hair et al. 
(2006); Stahl (2008); Yatim 
(2008) 

Anglim (2007); Doloi et al. 
(2011); Gaskin (2013e); Hair 
et al. (2006); Roh et al. 
(2005); Tabachnick and 
Fidell (1996); Stahl (2008); 
Yatim (2008) 

Hoyle (2011); Marsh, Hau and 
Wen (2004); McQuitty and 
Wolf (2013); Nunkoo and 
Ramkissoon (2012); Reisinger 
and Mavondo (2007) 


CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit 


Index; NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative 
Square Error of Approximation. 
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The variables for business success (Level 4) are distributed 
between Process success and Deliverable success. However, 
project professionals also take note that unintended impacts 
and consequences somehow form part of the model of project 
success. It does, however, seem that these are separated from 
other measures of project success considerations in that they 
cannot be taken into account. 


Results for Waterfall projects 


The data can be separated into projects conducted using the 
Waterfall and Agile methods, the purpose being to determine 
if there are differences in how project success is perceived and 
determined between the two methods. 


Four factors closely mirroring those of the Overall results 
were obtained. The factors were once again confirmed as 
valid with a Cronbach alpha value of above 0.9 for all of them. 
Table 6.3 indicates the factors loading for each variable and their 
associated factors. 


Slightly less clarity is obtained from this analysis because the 
number of responses is now less than in the Overall view. On the 
face of it, the result is very similar to that of the Overall result. 
The factor groupings remain the same as in Table 6.1: 


e Factor 1: Deliverable success. The only difference is the 
omission of the Goals and Objectives variable, which is now to 
be found in Factor 3, Process success. This could be because 
Waterfall projects are very structured and are initiated with the 
goal of the project in mind right from the start. 

e Factor 2: Strategic success. Is identical to that of the Overall 
result. 

e Factor 3: Process success. Is identical except for the variables 
discussed above and for the addition of one variable associated 
with business success. Interestingly enough, this variable is 
Governance. In order for the factors and model to make sense, 
governance is required. As a Waterfall project follows a very 
rigid and formalised approach, strong governance lies at the 
heart of it. 
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TABLE 6.3: Factors for project success with a Pattern Matrix (Waterfall). 


Observed Factor 

variable? 1 2 3 4 
DS_04 0.898 

DS_O3 0.861 

DS_O6 0.794 

DS_07 0.694 

DS_05 0672 

DS_02 0.653 

BS_04 O517 

DS_O1 0.393 0.304 

BS_02 0.363 0.360 

SS_05 0.834 

SS 06 0.746 

SS_04 0.725 

Ss 01 0.721 

$S_03 0.590 

$502 0.517 

PS_O1 0.803 

PS_04 O767 

PS_O3 0.766 

PS_O2 0.678 

BS_01 0.398 0.462 

BS_03 0.319 

BS_O5 0.812 
BS_06 0.738 


Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and 
Rotation Method: Promax with Kaiser Normalisation. 
a, Variable names and associations are presented in Appendix A. 


e Factor 4: Unknowns. Of a project success also remains 
unchanged. 


The SEM model (Figure 6.4) for these factors is also generated 
and revealed to be as such. 


Here even stronger interrelationships are identified, the 
strongest relationship once again being between Process success 
and Deliverable success. This correlation is very strong. This 
would imply that the outcome in the preceding level of Process 
success would directly and very strongly impact Deliverable 
success. This is a clear indication on how the Waterfall method 
impacts the outcome. The Waterfall method is initiated with a set 
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FIGURE 6.4: Unconfirmed model for Waterfall project success levels. 
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goal in mind to deliver a specific product. To obtain this product, 
many processes are performed in an iterative fashion. 


The model fit measures for this results were obtained as 
depicted in Table 6.4. 


The proposed model can be confirmed given the model fit 
measures. It is clear that the conclusions for the Overall model 
also apply to Waterfall projects. The one aspect that that is 
different is how strongly goals and objectives are associated 
with Level 1, Process success. 


Results for Agile projects 


The Agile method requires that its adherents only do what is 
required to successfully complete the delivery of a product. This 


TABLE 6.4: Model fit for Waterfall project success mode. 


Model fit Description Cut-off Results Reference 
measures levels 
employed 
Absolute fit CMIN/DF <5 Dell Gaskin (2013e); Marsh and 
measures Hocevar (1985); McKinney et al. 


(2002); Roh et al. (2005); Ullman 
(1996); Yatim (2008) 


RMR ZOOS 0.04 Roh et al. (2005); Tabachnick and 
Fidell (1996) 
GFI >0.9 0.92 Doloi et al. (2011); Kim et al. 


(2009); Roh et al. (2005); 
Tabachnick and Fidell (1996) 


Relative fit NFI 20.9 0.93 Doloi et al. (2011); Stahl (2008); 
measures Tabachnick and Fidell (1996); 
Yatim (2008) 
TEI 20.9 0.94 Hair et al. (2006); Doloi et al. 
(2011); Stahl (2008); Yatim (2008) 
CFI 2> 0.95 0.95 Anglim (2007); Doloi et al. (2011); 


Gaskin (2013e); Hair et al. (2006); 
Roh et al. (2005); Stahl (2008); 
Tabachnick and Fidell (1996); 
Yatim (2008) 


Fit measures RMSEA < 0.08 0.06 Hoyle (2011); Marsh et al. (2004); 
based on the McQuitty and Wolf (2013); 
non-central Reisinger and Mavondo (2007); 
chi-square Nunkoo and Ramkissoon (2012) 


distributions 


CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit Index; 
NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative Fit Index; RMSEA, Root Mean Square 
Error of Approximation. 
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approach in no way absolves its adherents of the requirement of 


a formalised approach. 


The results in this data set once again yielded the same 
four factors as found in the Overall and Waterfall models. All 
four factors were confirmed as valid with a strong Cronbach 
alpha above 0.9. The factor loadings obtained are depicted in 


Table 6.5. 


¢ Factor 1: Deliverable success. Is identical to that of the Overall 
model. This of course differs from the Waterfall project factors 
where objectives and goals are excluded in favour of Factor 3: 
Process success. For Agile projects, it seems that objectives 


TABLE 6.5: Factors for Agile project success with Pattern Matrix. 


Observed 
variable? 


DS_06 
DS_03 
DS_02 
DS_01 
DS_04 
DS_07 
BS_O1 
BS_04 
DS_05 
BS_02 
SS_03 
SS_02 
SS_01 
SS_04 
SS_06 
SS_05 
PS_03 
PS _04 
PS_01 
PS_02 
BS_O5 
BS_06 


Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and 


0.745 
0.729 
0.723 
0.714 
0.500 
0.433 


Rotation Method: Promax with Kaiser Normalisation. 


a, Variable names and associations are presented in Appendix A. 


0.749 
0.733 
0.667 
0.607 


1.019 
0.509 
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and goals form part of Factor 1: Deliverable success. This may 
be because, in Agile projects, not all requirements are 
immediately visible or identified but only developed during 
further iterations of the process. 

e Factor 2: Strategic success. Is identical to all previous results. 

e Factor 3: Process success. Is identical to the Overall result and 
only differs from the Waterfall projects’ results in two aspects. 
The model for Agile project success does (1) not require 
governance or (2) goals and objectives variables must be 
coherent. This is an interesting result, given the propensity for 
many Agile adherents to summarily dispense with valuable, 
formalised techniques. Governance is the activity of guiding 
behaviour to achieve a desired outcome and objective (Joseph, 
Erasmus & Marnewick 2014). The fact that the respondents to 
this questionnaire who practice Agile principles do not see value 
or need for governance as a contributing factor project success 
is cause for concern. 


The Agile project success model was derived as in Figure 6.5. 


This model once againindicates medium to strong relationships 
between the four factors that were confirmed. Table 6.6 shows 
the model fit measurements that were obtained. 


This model is also confirmed as valid and can be accepted. 
The medium to strong relationship indicates that once again 
there are influences amongst the levels of project success that 
cannot be ignored. 


E Development and analysis of IS 
project complexity models 


It must be noted that, unlike the IS project success models 
presented above, no viable or feasible SEM models were 
possible for all complexity constructs. Exploratory models are 
subsequently presented as they still provide insight regarding 
what complexity features to consider for IS projects. 
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FIGURE 6.5: Unconfirmed model for Agile project success levels. 
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TABLE 6.6: Agile model fit measurements. 


Model fit Description Cut-off Results Reference 
measures levels 
employed 
Absolute fit CMIN/DF <5) 2.8 Gaskin (2013e); Marsh and 
measures Hocevar (1985); McKinney et al. 


(2002); Ullman (1996); Roh 
et al. (2005); Yatim (2008) 


RMR < 0.05 0.04 Roh et al. (2005); Tabachnick 
and Fidell (1996) 
GFI 20.9 0.92 Doloi et al. (2011); Kim et al. 


(2009); Roh et al. (2005); 


Tabachnick and Fidell (1996); 
Relative fit NFI 20.9 0.93 Doloi et al. (2011); Stahl (2008); 
measures Tabachnick and Fidell (1996) 
Yatim (2008) 
TLI 20.9 0.91 Doloi et al. (2011); Hair et al. 
(2006); Stahl (2008); Yatim 


(2008) 
CFI > 0.95 0.95 Anglim (2007); Doloi et al. 


(2011); Gaskin (2013e); Hair 

et al. (2006); Roh et al. (2005); 
Stahl (2008); Tabachnick and 
Fidell (1996); Yatim (2008); 


Fit measures RMSEA < 0.08 0.06 Hoyle (2011); Reisinger and 
based on the Marsh et al. (2004); Mavondo 
non-central (2007); McQuitty and Wolf 
chi-square (2013); Nunkoo and 
distributions Ramkissoon (2012) 


CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit 
Index; NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative Fit Index; RMSEA, Root Mean 
Square Error of Approximation. 


Organisational complexity and project 
success 


Organisational complexity was identified as the IS project 
complexity construct with the most features at 34. Furthermore, it 
was depicted and discussed that organisational complexity spans 
across all the project success levels. Exploratory factor analysis 
(EFA) was performed to determine the latent constructs within 
organisational complexity from an Overall, Agile and Waterfall 
perspective. However, the EFA process was unsuccessful as a valid 
and reliable exploratory model could not be determined based on 
the current dataset. It was therefore established that future studies 
will have to be performed to gain a better understanding and clarity 
around the organisational complexity construct for IS projects. 
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The irony that organisational complexity is complex to articulate 
further iterates the importance of understanding this construct. 


Environmental complexity 


Failure of the organisational complexity EFA process resulted 
in environmental complexity being analysed independently as 
this would still provide value regarding what complexities to 
assess from an environmental perspective. Similarly, EFA was 
performed from an Overall, Agile and Waterfall perspective. 


O Overall exploratory factor analysis modelling 
of environmental complexity 


Various measures were applied when validating the discovered 
exploratory models. Firstly, the Kaiser-Meyer-Olkin (KMO) was 
assessed at 0.848, which is a very good adequacy measure 
(Field 2009; Gaskin 2016; Kaiser 1974). The KMO value was 
also significant (0.000), which further validates this adequacy 
measure. Extraction values from the communalities results are 
also used to determine adequacy and are required to be above 
0.3 (Gaskin 2016). This was confirmed as all values were above 
the acceptable threshold. The total variance explained is another 
adequacy measure which needs to be assessed. The threshold 
for this measure is preferably above 50% (Gaskin 2016; Reio & 
Shuck 2015), but the result was 44.4%. For the sake of research, 
the results of this EFA will still be discussed as the other validity 
and reliability measures were acceptable. Convergent validity was 
established via factor loadings, which are required to be above 0.5 
with an average loading, within a factor, of above 0.7 (Ferguson 
& Cox 1993; Gaskin 2016; Hair et al. 2006). Table 6.7 presents 
the factor loadings and reveals that further validation is required 
to confirm the loading values. Cronbach’s alpha was used as a 
reliability check with the threshold set at 0.7 (Badewi 2016; Chow 
& Cao 2008; Hair et al. 2006). Cronbach values are represented in 
Table 6.7 next to the factor number in brackets. Both values are 
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TABLE 6.7: Environmental complexity exploratory factor analysis Patten Matrix. 


Observed variable? Factor 
1 (0.860) 2 (0.811) 

EC_09 0.779 

EC_O8 0.701 

EC 07 0.678 

EC_13 0.664 

ECOG 0.542 

EC_2 0.542 

ECHO 0.513 

EC_O5 0.496 

EC ol 0.470 

EC_04 0.419 

EC Ol 0.867 
EC_02 0.835 


a, Variable names and associations are presented in Appendix A. 


acceptable as Factor 1 and Factor 2 have a score of 0.860 and 
0.811 respectively and confirm the factor loadings. Discriminant 
validity was assessed via the factor correlation matrix where there 
should be no correlations above O.7 (Gaskin 2016). The correlation 
between Factor 1 and Factor 2 was below the threshold at 0.533. 


A factor plot is also used to visualise the groupings for each 
factor (Figure 6.6). It must be noted that factor plot diagrams can 
only represent three factors effectively as they are limited to three 
dimensions. The groupings are distinct and confirm the loadings. 


An exploratory model for the environmental complexity of IS 
projects is depicted in Figure 6.7. The EFA revealed that one 
factor had to be removed, that is political influence (EC_O3). 
Political influence, therefore, has no effect on IS project 
complexity and subsequently IS project success. Political 
influence could be a feature which must be handled by external 
parties such as senior management, as the project should be 
left to its own devices to deliver as required. Factor 1 is labelled 
strategic and tactical conditions as the inherent features revolve 
around strategic aspects such as internal strategic pressure 
and level of competition. Strategic aspects focus on the greater 
project goal and its relation to strategic intent. Tactical aspects 
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FIGURE 6.6: Environmental complexity factor plot diagram. 


Strategic and tactical conditions Stakeholder management 
¢ Internal support 

¢« Required local content 

e Weather conditions 

¢ Interference with existing site 

*« Remoteness of location 

¢ Experience in country 

¢ Internal strategic pressure 

. Level of competition 

¢ Stability of project environment 
e Environmental risks 


e Number of stakeholders 


e Variety of stakeholder 
perspectives 


Environmental 
complexity 


FIGURE 6.7: Exploratory model for environmental complexity of information system project. 


include, amongst others, remoteness of location, experience in 
the country, risks and weather conditions. Tactical aspects focus 


on practices and considerations around ground level activities of 
the project itself. 
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0 Agile exploratory factor analysis modelling of 
environmental complexity 


The Agile EFA model of environmental complexity applies the 
same acceptance criteria as before. The KMO was significant 
(0.000) and accepted at 0.849. All extraction values are above 
the 0.3 threshold. Total variance explained is accepted on the 
limit at 50%. Factor loadings presented an issue again, thus 
Cronbach alpha was applied. The results were 0.823 and 0.832 
for Factor 1 and Factor 2 respectively (Table 6.8). Reliability and 
factor loading validity are therefore accepted and confirmed. 
The correlation between Factor 1 and Factor 2 was below the 
threshold at 0.558. 


Distinct groupings are represented in the factor plot diagram 
(Figure 6.8). Complexity features EC_05, EC_0O6, EC_O7 and 
EC_O9 were removed to enhance EFA model validity and 
reliability. 


The results imply required local content, interference with 
existing site, weather conditions and experience in a country 
are not complexity features for Agile projects. Local content 


TABLE 6.8: Environmental complexity exploratory factor analysis Patten Matrix (Agile). 


Observed variable? Factor 
1 (0.823) 2 (0.832) 

ECHOS) 0.892 

EC_13 0.687 

ECHO 0.644 

EC_11 0.628 

ECROS 0.526 

EC_12 0.447 

ECROS 0.829 
EC_02 0.772 
ECKO 0.737 
EC_04 0.596 


a, Variable names and associations are presented in Appendix A. 
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FIGURE 6.8: Environmental complexity factor plot diagram when using Agile. 


requirement is arguably not an issue for Agile projects as they 
adapt and reconfigure where necessary to accommodate the 
use of local content-based policies where the project is being 
executed. Similarly, the same could apply for interference with 
the existing site. Protest action for example does not influence 
Agile projects as it is dealt with on an ad hoc basis and initiative 
is taken to continue where possible and minimise productivity 
loss. Weather conditions was continuously ranked in the bottom 
five features in Chapter 5 and is confirmed here as a poorly 
represented complexity feature. Experience in a country may not 
effect Agile projects as the projects draw on their own experience 
from various projects to accommodate for country differences. 
The exploratory model for Agile projects is similar to the Overall 
model as the latent factors remain stakeholder management as 
well as strategic and tactical conditions (Figure 6.9). 
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Strategic and Tactical conditions Stakeholder management 


e Remoteness of location 

e Internal strategic pressure 

e Stability of project environment 
e Level of competition 

e Environmental risks 


e Number of stakeholders 

e Variety of stakeholder 
perspectives 

e Political influence 

e Internal support 


nvironmental 
complexity 
(Agile) 


FIGURE 6.9: Exploratory model for environmental complexity (Agile). 


TABLE 6.9: Environmental complexity exploratory factor analysis Patten Matrix (Waterfall). 


Observed variable? Factor 
1(0.799) 2 (0.793) 

EG Ol 0.971 

EC_02 0.747 

EC il 0575 

EC_O3 0.525 

E109 0.787 
EC_O7 0.722 
EC 08 0.667 
EC_13 0.610 


a, Variable names and associations are presented in Appendix A. 


£O Waterfall exploratory factor analysis modelling 
of environmental complexity 


The Waterfall EFA model came in at a KMO of 0.720, which is 
low but acceptable. Extraction values were sufficiently above 
the 0.3 threshold. Total variance was 53% and met adequacy 
criteria. Individual factor loadings were above O.5 where 
Factor 1 averaged 0.704 and Factor 2, 0.696 (Table 6.9). This 
discrepancy was addressed via Cronbach alpha tests where 
the results were 0.799 and 0.793 for Factor 1 and Factor 2. 
respectively. The correlation matrix revealed a low, accepted 
correlation of 0.303. 


The groupings are further reiterated in Figure 6.10. 


The exploratory model for Waterfall projects is presented in 
Figure 6.11 and shows a different take on environmental complexity 
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Factor plot in rotated factor space 
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FIGURE 6.10: Environmental complexity factor plot diagram (Waterfall). 


Project site and location Stakeholder management 


e Weather conditions « Number of stakeholders 

e Remoteness of location Environmental e Variety of stakeholder 

* Experience in country complexity perspectives 

e Environmental risks e Political influence 

¢ Stability of project 
environment 


(Waterfall) 


FIGURE 6.11: Exploratory model for environmental complexity (Waterfall). 


Stakeholder continues to manifest for Waterfall projects, 
which arguably confirms its importance regardless of project 
methodology. Waterfall projects include complexity related to 
project environment stability and implies that Waterfall projects 
are affected more significantly when the environment is unstable. 
This could be attributed to the rigid, structured nature of the 
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Waterfall method where a systematic approach is adopted and 
complied with from the outset. Project site and location is the 
second latent factor identified which differs significantly from the 
Overall and Agile views. Interestingly, Waterfall projects place more 
emphasis on weather conditions, location remoteness, experience 
in country and environmental risks. The remaining complexity 
features were omitted. Environmental risks in the context of 
Waterfall projects arguably pertain to site and location risks more 
than anything else. Waterfall projects thrive on extensive upfront 
planning which aims to negate future issues. This could be why 
physical environmental aspects plan such an important role as 
they are often underestimated or not completely understood. 


The following section covers the remaining IS project 
complexity constructs and their EFA analysis. 


Technical complexity, dynamics and 
uncertainty 


Technical complexity, dynamics and uncertainty were mapped 
within the process and project management success scope. 
This formed the basis for the next EFA analysis as these three 
constructs were analysed together to determine complexities 
which are associated with the first two IS project success levels. 


Overall exploratory factor analysis 
modelling of technical complexity, 
dynamics and uncertainty 


Similar to previous modelling practice, the same validity and 
reliability measures were adopted. The KMO is 0.933 while all 
extraction values are above 0.3. The five factors presented in Table 
6.10 provide a total variance of 56% which is acceptable. Factor 
loadings meet the acceptance criteria thus Cronbach’s alpha is 
used to determine further reliability. The results are 0.901, 0.883, 
0.848, 0.835 and 0.812 for Factor 1 to Factor 5 respectively. All 
results are sufficiently above the acceptance level of 0.7 and thus 
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TABLE 6.10: Technical complexity, dynamics and uncertainty exploratory factor analysis 
Pattern Matrix. 

Observed Factor 

variable* 1(0.901) 2 (0.883) 3 (0.848) 4 (0.835) 5 (0.812) 
UOS 0.869 

U_O6 0.791 

U_04 0.788 

U_O1 0.738 

URO 0.651 

U_08 0.637 

UEO 0.629 

U_02 0.613 

u_o9 0.547 

U_O3 0.516 

D_0O2 1.067 

D_04 0.772 

D O Oms 

D_01 0.547 

D OS 0.473 

D_0O6 0.459 

TESO 0.948 

TC_08 0.911 

TEOS 0.576 

TC12 0.529 

1E2005 0.391 

TC_09 0.326 

TEOS 0.870 

TC_04 0.780 

Tee 0.542 

TET 0.969 
TES 0.667 


a, Variable names and associations are presented in Appendix A. 


confirm the identified factors. Discriminant validity is achieved as 
the factor correlation matrix reveals no correlations above 0.7. 
As discussed previously, a factor plot diagram cannot be used 
where more than three factors exist as the diagram is no longer 
decipherable and provides no extra analysis value. 


As per Figure 6.12, the EFA results revealed five factors, (1) 
technology experience, (2) project goals, (3) project scope and 
tasks, (4) dynamics and (5) uncertainty. 
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Technology experience Project goals Project scope and tasks 

* Scale of scope 

* Quality requirements 

* Number of tasks 

e Variety of tasks 

* Conflicting norms and 
standards 

e Technical risks 


e Newness of * Number of goals 


technology * Goal alignment 


e Experience with e Clarity of goals 
technology 


Technical, 
Dynamics 
and Uncertainty 
complexity 


Change management 
*« Change process 


Uncertainty 
Uncertainties in scope 
Uncertainties in cost 
Uncertainties in time 
Uncertainty in methods 
Task uncertainty 
Uncertainty of goals and 
objectives 
Technological maturity 
and novelty 
Undisclosed participants 
* Competency 

* Incomplete information 


. Number of changes 


* Scope of changes 


*« Frequency of changes 


¢ Impact of changes 


*« Change over time 


FIGURE 6.12: Exploratory model for technical complexity, dynamics and uncertainty of 
information system projects. 


IS projects experience complexities regarding technology 
usage as experience and adoption are the two features to be 
constantly monitored. Given that IS projects thrive on technology 
usage, whether as a project tool or for project implementation, 
technology plays a pivotal role as experience is necessary for 
effective usage. Furthermore, experience should be facilitated 
through continuous development of project team members to 
ensure they use appropriate technology for any given IS project. 
The latent factor of project goals was apparent and signified the 
importance of effective goal management. The number of goals 
together with goal clarity and alignment are three prerequisites 
required for any project, regardless of the methodology 
employed. Complexities associated with these three features are 
arguably the key reasons why IS projects perform poorly and 
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do not deliver planned benefits. IS project managers and their 
teams become so obsessed with delivering within time and cost 
that key fundamentals like goal delivery are negated. Moreover, 
project goals relate directly to the next factor of project scope 
and tasks. Project tasks are based on the project scope, which 
in turn is directly influenced by the set goals. The scale of the 
scope determines the number and variety of tasks required 
to execute the project. Conflicting norms and standards do, 
however, hinder tasks and activities as various stakeholders 
abide by different policies and procedures especially with regard 
to their requirements. This is arguably evident by the inclusion of 
technical risk in the project scope and tasks factor as risks arise 
when transitioning from scoping activities to actual project task 
execution. 


The fourth factor perfectly maps the six features of dynamics 
to change management as argued in the theoretical mappings 
presented in Chapter 3. Change management is paramount to IS 
projects as the intangible nature of these projects often results in 
multiple changes as required particularly during implementation. 
Change practices therefore have to be sound and promote 
effective change regardless of what is required. Furthermore, 
not all changes are positive as previously mentioned, thus these 
changes must be mitigated and addressed through a robust set 
of practices. The following question can thus be posed: What 
change practices should be in place for IS projects to maintain 
their momentum and experience minimal disruption? Future 
research should address this contentious question. The final 
factor of uncertainty also fully encapsulates the theoretical 
mappings presented in Chapter 3 and confirms the role of 
uncertainty in IS projects. Rather than focusing on what is 
known, IS projects should be cognisant of what is unknown so 
that when the uncertainty arises a more proactive mindset is 
instilled for addressing uncertainty. Awareness does not imply 
that a plan exists for any uncertainty incident, it implies that the 
overall impact is recognised and will not be a ‘shock’ for parties 
involved. 
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O0 Agile exploratory factor analysis modelling 
of technical complexity, dynamics and 
uncertainty 


The Agile EFA has a KMO of 0.858 and all extraction values are 
above 0.3. Total variance explained equalled 58%, which is well 
within the threshold criterion. Only Factor 1 has factor loading 
lower than 0.5 but Cronbach’s aloha was performed regardless 
as part of the reliability check. Factor 1 to Factor 5 have Cronbach 
alpha’s of 0.892, 0.856, 0.786, 0.800 and 0.782 respectively. 
Factor loading validity and reliability is therefore confirmed. 
The factor correlation matrix (Table 6.11) also confirmed 
discriminant validity as no correlation above O.7 exists. 


TABLE 6.11: Technical complexity, dynamics and uncertainty exploratory factor analysis 
Pattern Matrix (Agile). 

Observed Factor 

variable? 1 (0.892) 2 (0.856) 3 (0.786) 4 (0.800) 5 (0.782) 
TC_07 0.991 

Tc_2 0.769 

TELOS 0.754 

TC_O6 0.685 

TELON 0.599 

TC_O5 0.594 

TC_O9 0.434 

U_O5 0.804 

U_04 0.778 

U_O1 0.737 

URO 0.594 

U_02 0.573 

URO 0.532 

U_O3 0.521 

U_08 0.515 

D_02 1.054 

DAOA 0.583 

TEN 1.014 

TC_10 0.556 

TC_04 1.033 
TC_03 0.534 


a, Variable names and associations are presented in Appendix A. 
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The five factors are identified as per Figure 6.13: 


e Factor 1: Project scope and tasks. 
e Factor 2: Uncertainty. 

e Factor 3: Change management. 

e Factor 4: Technology experience. 
e Factor 5: Project goals. 


Although the factors are similar to the overall view of IS 
projects, their composition is somewhat different. 


Agile projects seem to have the added complexity of multiple 
inputs and outputs. IS projects use and produce various inputs and 
outputs throughout until final delivery. Agile projects arguably have 
more inputs and outputs as the iterative philosophy leads to multiple 
instances of these events. Furthermore, managing multiple inputs 
and outputs can become a cumbersome process and escalate to a 
point where the Agile mindset is its own worst enemy. Uncertainty 
is the second factor which also has a different composition as goal 
and objective as well as competency uncertainty are omitted. 
Goal and objective uncertainty is possibly less of a ‘bugbear’ as 
Agile embraces changes through flexible adaptive practices. More 
interestingly is the exclusion of competency uncertainty which 
contends that competency deficiencies could hamper a project’s 


Project scope and tasks 


¢ Number and diversity of 
inputs and/or outputs 

* Scale of scope 

* Quality requirements 

e Number of tasks 

e Variety of tasks 

* Conflicting norms and 
standards 

e Technical risks 


Uncertainty 


Change management 


¢ Uncertainties in scope 

e Uncertainties in cost 

e Uncertainties in time 

¢ Uncertainty in methods 

¢ Task uncertainty 

* Technological maturity 
and novelty 

¢ Undisclosed participants 

* Incomplete information 


echnical, 
Dynamics 
and Uncertainty 
complexity 


Technology experience 
. Newness of technology 


* Experience with technology 


(Agile) 


. Number of changes 
*« Scope of changes 


Project goals 


* Goal alignment 
e Clarity of goals 


FIGURE 6.13: Exploratory model for technical complexity, dynamics and uncertainty (Agile). 
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progress. Agile projects also embrace competency deficiencies by 
identifying these as they occur and addresses them while continuing 
with the project. Furthermore, the flexibility promoted by Agile 
allows resources reallocation especially for skill set acquisition. 
Change management is only represented by the number and scope 
of changes for Agile projects. The omission of other features implies 
Agile projects are only concerned with the number and scope of 
changes. Logically this makes sense given the iterative approach 
adopted. An argument could be made that an overwhelming number 
of changes and/or extensive change scopes could derail change 
management practices. Addressing these two complexities would 
indirectly address the omitted features of change management. 
Technology experience remains stable as the two features are the 
same as the Overall view. Project goals, on the other hand, have also 
changed relatively as only goal alignment and clarity are considered 
complexities for Agile projects. The number of goals is no longer 
an issue as the Agile method promotes incremental development 
where multiple goals are addressed efficiently. However, there 
has to be clear alignment between goals to ensure Agile practices 
deliver the correct project and business benefits. 


O Waterfall exploratory factor analysis modelling 
of technical complexity, dynamics and 
uncertainty 


The EFA process for Waterfall projects has an acceptable KMO of 
0.876 and extraction values above the 0.3 threshold (Table 6.12). 
Total variance explained is an excellent 62%. The factor loadings 
required reliability confirmation using Cronbach's alpha. Factor 1 
to Factor 5 have alphas of 0.884, 0.888, 0.827, 0.747 and 0.863 
respectively. Discriminant validity is accepted as no correlations 
above 0.7 exist in the factor correlation matrix. 


The five factors are once again similar as presented in Figure 6.14: 


e Factor 1: Uncertainty. 
e Factor 2: Change management. 
e Factor 3: Technology experience. 
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TABLE 6.12: Technical complexity, dynamics and uncertainty exploratory factor analysis 
Pattern Matrix (Waterfall). 

Observed Factor 

variable? 1 (0.884) 2 (0.888) 3 (0.827) 4 (0.747) 5 (0.863) 
U_04 0.813 

U_06 0.809 

ULOS 0.804 

U_O1 0.674 

UROS 0.625 

U_10 0.606 

EOS 0.595 

U_02 0.575 

1C205 0.300 

D_02 1.015 

DIO3 0.821 

D_04 0.732 

D_O1 01552 

D_O6 0.475 

u_o9 0.394 

TCM 0.898 

TEO 0.809 

TC_12 0.595 

TEO 0.996 

TC_O7 0.485 

ieee 0725 
TC_04 0.664 


a, Variable names and associations are presented in Appendix A. 


e Factor 4: Project scope and tasks. 
e Factor 5: Project goals. 


The composition has once again changed for Waterfall projects. 


The uncertainty factor now includes uncertainty of goals and 
objectives but omits competency and technological maturity 
and novelty. This implies competency is not a complexity feature 
and that technological maturity and novelty do not influence 
Waterfall projects. Interestingly, scale of scope is included 
which is commonly associated with project scope complexities. 
This grouping implies that scale of scope has inherent 
uncertainties regardless of project requirement size. Change 
management excludes the impact of changes but encapsulates 
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Uncertainty Change management Technology experience 
ieee its in Scope * Change process . Newness of technology 
e Uncertainties in cost 
. Uncertainties in time . Number of changes * Experience with 
e Uncertainty in methods * Scope of changes technology 


* Task uncertainty 

¢ Uncertainty of goals and 
objectives * Change over time 

e Undisclosed participants e Competency 

* Incomplete information 

* Scale of scope 


e Frequency of changes | | * Technical risks 


echnical, 
Dynamics 
and Uncertainty 
complexity 


Project scope and tasks Waterfall) Project goals 
¢ Number of tasks * Goal alignment 
e Variety of tasks e Clarity of goals 


FIGURE 6.14: Exploratory model for technical complexity, dynamics and uncertainty 
(Waterfall). 


the remaining five features based on the theoretical mappings. 
The surprising inclusion of competency in change management 
begs the question of whether adequate competencies exist for 
addressing any change request in Waterfall projects. It could be 
that competencies required to implement changes are inadequate 
and lacking thus resulting in deferred delivery date. Technology 
experience expands to include technical risks, which is arguably 
a logical inclusion given that technology inherently has risks 
associated with it regardless of experience or newness. Waterfall 
projects are only concerned with the number of tasks and variety 
of task complexities. These low level complexities pertain to the 
planning phase of project management as the Waterfall method 
places emphasis on extensive details. Any planning discrepancies 
which arise during subsequent phases result in derailing the 
project as tasks have to be reallocated and realigned on an ad 
hoc basis. This inadvertently delays other aspects of an IS project. 
Project goals is the fifth and final factor for Waterfall projects. 
Similar to Agile projects, goal alignment and clarity are the two 
pillars supporting project goal complexity. Given that Waterfall 
projects emphasise upfront planning, any volatility with either 
feature results in adverse effects on all project activities. 
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E Conclusion 


The gathered data indicated that, in the information systems 
project industry, we are dealing with various levels of project 
success. How they operate in practice may differ slightly in detail. 
Regardless of which method or approach is followed, IS project 
managers are aware of process success, strategic success, 
project management success and, most vitally, deliverable or 
product success. It can be surmised that this is the focus of IS 
project management when it is viewed holistically. 


Remarkably very few differences are observed between Agile 
and Waterfall projects. In most respects they are very similar. 
The following differences are observed: 


1. The overall correlations between the factors in Waterfall 
projects are stronger than in those of Agile projects. This 
could indicate that the structured and more formalised 
approach of Waterfall projects have greater effects on 
subsequent levels of projects success. 

2. Objectives and goals seem to be important to Waterfall 
projects in the process success factor, while in Agile projects 
these considerations are important in the deliverable success 
factor. This may point to a difference in focus between the 
two methods. 

3. The aspect of governance seems to play a role with Waterfall 
projects and not at all with Agile projects. This may once again 
be a symptom with regard to the underlying philosophy of 
each. What could be at issue here is the fact that the 
respondents indicated their own perceptions and as such 
improperly utilise governance in projects. 


What holds for all three confirmed models is the fact that there 
does seem to be medium to strong interrelationships between 
all these factors. As these factors can be mapped to Bannerman 
(2008) levels, this dataset indicates that the outcome of lower levels 
could have an impact on higher levels. Therefore it is important 
to successfully complete project processes in order to facilitate 
project deliverable success as well as ultimate strategic success. 
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The EFA analysis of the various constructs clearly and 
interestingly showed that, although each environment has the 
same number of latent factors, the composition of factors is often 
different. Arguing that project complexity is uniform regardless 
of type is clearly rejected, as these results show that within the 
IS project landscape there are variations when adopting the 
prevalent approaches of Systems Development Life Cycle and 
Agile. IS project complexity is clearly not uniform or consistent as 
different complexities are evident depending on methodology. 
The exploratory nature of the complexity results suggests further 
investigation to validate the above claims as more variation could 
occur upon further analysis. The EFA models presented act as 
preliminary results and form the foundation of further studies. 
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complex and chaos 


The conclusion that one can make at the end of this book is that 
IS project success and IS project complexity is not about absolute 
numbers but more about a mindset. This mindset should be 
focused on two aspects: The first aspect is that IS project success 
is measured on a continuum and the second aspect is that IS 
project complexity needs to be appreciated for what it is, that is 
complex. 


The framework of Bannerman (2008) is used to create this 
mindset of IS project success as a continuum. Five levels exist 
within this framework, and an IS project can be successful 
at any one of these levels. The preference is that the project 
should be successful at all five levels but this is not possible 
in real life. Each level addresses a different aspect of success. 
More importantly, the framework forces all the stakeholders 
to take ownership for IS project success. IS project success is 
not the responsibility of just the project manager but it is the 


How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Simple, complicated, 
complex and chaos’, in The symbiosis between information system project complexity 
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responsibility of all the stakeholders. Specific stakeholders will 
have different inputs, insights and influences at the different 
levels, but at the end of the day it is everyone’s responsibility to 
ensure IS project success. 


The results depicted in Chapter 4 highlight that the success 
rates have improved. This improvement is directly related to the 
fact that success is measured on a continuum. When the results 
are interrogated a little further, it is evident that success at a 
business and strategic level is still at 62% and 59% respectively. 
This creates an opportunity for organisational leaders to improve 
the success rates and reap more benefits and value from the 
investment in IT. The results also indicate that Agile projects 
are more successful than Waterfall projects. This can result in 
a product that is delivered by an Agile project being released 
quicker to the market, thereby creating faster business and 
strategic success than Waterfall projects. It might be worthwhile 
for organisational leaders to invest in Agile as a method to deliver 
IS projects quicker. This said, the emphasis should still be on 
delivering these types of projects successfully at all five levels. 


The modelling of the success levels reduced the five levels 
to four levels. The last two levels (business and strategic) are 
merged into one level, that is strategic success. IS project success 
can then ultimately be measured as per Figure 7.1. 


Although the framework of Bannerman indicates that there 
is not necessarily a relationship between the different levels, 
that is one level does not necessarily affect the outcome of the 
next level, the results of SEM indicate that there are positive 
correlations between the different levels. This implies that the 
outcome of lower levels influences the outcome of higher levels. 


Project 3 F 
Process management Deliverable Strategic 


succes SUCCESS success 
SUCCESS 


FIGURE 7.1: Information system project success levels. 
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IS project complexity itself is complex. Five constructs of 
complexity were identified simplifying the view of complexity. 
But beyond this simplified view, there are still 75 complexity 
features that need to be taken into consideration. The problem is 
that these 75 complexity features can appear in any combination 
within an IS project. This opens the door for an IS project to 
change from complex to chaos within the blink of an eye. The 
analysis of the top five features in every construct make one 
realise that there is actually no complexity feature that is more 
important than another or that one construct is more important 
than another construct. The results do suggest that technical 
and organisational complexity are the two main constructs that 
contribute to the complexity of IS projects. 


The modelling of complexity did not yield the desired 
results and only a suggestion of a possible model is provided. 
The modelling suggests that environmental complexity can be 
divided into stakeholder complexity and strategic complexity. 
Organisational complexity is intricate and should be dealt with 
in its entirety. The remaining three complexity constructs can 
be divided into five new constructs. This implies that the IS 
complexity can be viewed as eight new constructs instead of the 
original five constructs. Whether this makes IS complexity less 
complex, remains to be seen. 


The symbiotic relationship between IS project success and 
IS project complexity cannot be negated. This study could not 
provide a definite answer to the problem at hand. Figure 7.2 
provides insight into this symbiotic relationship. 


Complexity plays a significant role during the lower levels 
of IS project success as all eight constructs have an impact on 
process and project management success. When it comes to 
the deliverable and strategic success, then only three constructs 
play a role. 


What should organisational leaders and specifically IS project 
managers do in the face of complexity? The impression is created 
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Organisational complexity + Stakeholder complexity + Strategic/Tactical complexity 


hele Deliverable 


Process success management Strategic success 


success 
success 


Technology experience complexity 
Project goal complexity 

Project scope complexity 

Change management complexity 
Uncertainty 


% ca. a a. S 


FIGURE 7.2: Symbiotic IS project success and complexity model. 


that when IS project managers can manage the complexity 
surrounding IS projects, then there is a better chance that these 
projects will be delivered successfully. 


Snowden and Boone (2007:69) state that ‘wise executives 
tailor their approach to fit the complexity of the circumstances 
they face.’ This is also applicable to IS project managers that 
need to understand what they should do. The first step is to 
identify the level of complexity within the IS project. Four levels 
of complexity exist, namely simple, complicated, complex and 
chaotic. IS project managers should manage simple, complicated 
and complex projects in such a way that they do not become 
chaotic. The line between complex and chaotic is very thin. 


In conclusion, IS project managers cannot rely on the normal 
competencies as promoted by the various project management 
competency frameworks. They need to have additional 
competencies to deal with complexity as the IS domain will become 
more and more complex in the near future. This new understanding 
of complexity will allow IS project managers to address complexity 
and understand the impact it has on the success of a project. 


Knowledge and wisdom of IS project complexity will increase 
the success of IS projects and ultimately the value that IT provides 
to the organisation. 
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1. Project success variables 


Construct Feature Variable Name 
Process success Chosen PS_0O1 
Alignment PS_O2 
Integrated PS_O3 
Implemented PS_04 
Deliverable success Specifications Met DS_O1 
Requirements Met DS_02 
User Expectations DS_0O3 
User Acceptance DS_04 
Product Used DS_O5 
User Satisfied DS_O6 
Benefits Realised DS_0O7 
Business success Goals BS_O1 
Business Plan BS 02 
Governance BS 03 
Benefits Realisation BS_04 
Unintended Benefits BS 05 
Unintended Impacts BS_O06 
Strategic success Market Impact SS_O5 
Industry Impact SS_O5 
Competitive Impact SS_O5 
Investor Impact SS_O5 
Regulatory Impact SS_O5 
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2. Project complexity variables 


Construct Element Feature Variable 
Name 
Organisational Vertical differentiation Organisational structure ©OC Ol 
complexity Horisontal differentiation Organisational units OC 02 
Task structure OC_03 
Size Project duration OC_04 
Variety of methods and tools @©G205 
Capital expenditure OC_O6 
Work hours OC_O7 
Project team OC_08 
Site area OC 09 
Number of locations oeno 
Resources Project drive (OVE T 
Resource and skills availability OC 12 
Experience with involved parties ‘OEMS 
Health, safety, security and OCNA 
environment (HSSE) awareness 
Interfaces between different OC_15 
disciplines 
Number of financial resources OC_16 
Contract types OC 17 
Project team Number of different nationalities OC_18 
Number of different languages OG 19 
Cooperation with joint-venture OC_20 
partner 
Overlapping office hours OC 21 
Trust Trust in project team OC 22 
Trust in contractor OC 23 
Risk Organisational risks OC_24 
Interdependencies Environmental dependencies QOC 25 
Resource sharing OCHE 
Schedule dependencies OC- 27 
Interconnectivity and feedback OC_28 
loops in task and project networks 
Dependencies between actors ocg 
Information systems dependencies OCESO 
Objective dependencies OC_31 
Process interdependencies OC _ 
Stakeholder interrelations CES 
Team cooperation and OC_34 


communication 
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(continues...) 


Appendix 


Construct Element Feature Variable 
Name 
Technical Differentiation Number and diversity of inputs TC_O1 
complexity and/or outputs 
Goals Number of goals TC_O2 
Goal alignment TC_O3 
Clarity of goals TC_04 
Scope Scale of scope TC_O5 
Quality requirements TC_06 
Tasks Number of tasks TC_O7 
Variety of tasks TC_O8 
Conflicting norms and standards TC_O9 
Experience Newness of technology TC_10 
Experience with technology TCT 
Risk Technical risks TC_12 
Environmental Stakeholders Number of stakeholders EC_01 
complexity Variety of stakeholder perspectives EC_02 
Political influence ECOS 
Internal support EÇ 04 
Required local content EC 0S 
Location Interference with existing site EC 06 
Weather conditions ECHOF 
Remoteness of location EC_08 
Experience in country EC_09 
Market conditions Internal strategic pressure EC 10 
Stability of project environment EC_N 
Level of competition ECH 
Risk Environmental risks EÇ 13 
Uncertainty Triple constraint Uncertainties in scope u_o1 
Uncertainties in cost U_02 
Uncertainties in time U_O3 
Activity Uncertainty in methods U_04 
Task uncertainty U_O5 
Goals Uncertainty of goals and objectives U_O6 
Technology Technological maturity and novelty U_O7 
Stakeholders Undisclosed participants U_08 
Competency U_O9 
Information Incomplete information U_10 
Dynamics Change management Change process D01 
Number of changes D 02 
Scope of changes D103 
Frequency of changes D_04 
Impact of changes D 05 
Change over time D_O6 
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Writing a book on project management with an interplay between the success and 
complexity of projects is not only a challenge but also fills a very important gap in the 
literature. In this, the authors have succeeded exceptionally well. This book is highly 
recommended to all academics who are teaching project management. 


Awie Leonard, Associate Professor, Faculty of Engineering, Built Environment and 
Information Technology, University of Pretoria, South Africa 


Complexity is one of the major aspects that trips up project success, and this book 
makes a valuable contribution to defining the sources of complexity in projects 
and how they affect the project outcome. As a project-management practitioner, | 
thoroughly enjoyed the different definitions of project success. Too often, we only 
focus on the triple constraint of time, cost and scope (project and process success) 
rather than on the success of the product and the overall business and commercial 


SUCCESS. 


Josef Langerman, Executive Group Head for Engineering Transformation at 
Standard Bank and Visiting Associate Professor at the 
University of Johannesburg, South Africa 


A growing number of researchers suggests that information systems are more 
appropriately conceived as complex socio-technical systems. This book explores 
numerous dimensions of complexity - dimensions such as organisational and 
technical complexity. Its timely investigation is insightful and will stimulate further 
thoughts and discussion within the academic community. That is why this book is so 


valuable. 


Rennie Naidoo, Associate Professor Department of Informatics, 


University of Pretoria, South Africa 
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